[MBDyn-users] Finite element coupling
masarati at aero.polimi.it
masarati at aero.polimi.it
Sun May 9 20:38:36 CEST 2010
> I took a little bit of time to make sure to understand what I need.
> Solution #2 : it requires lots of iterations without to be sure to
> converge. So even if I am still curious about how it could work, I don't
> think it will be the best way to solve large analysis.
> Solution #3 : do you have documentation about it? I tried without success,
> I hope it is the best way for my analysis.
> I can summarize my analysis by this schema :
> +---+---+ /
> / / /|/
> +---+---+ o
> | | |/
> Of course real studis are a little bit more complex, but it is the same
> with more elements. So I would like to make a coupling between :
> - the first part (at the left) : some finites elements with a finite
> element software
> - the second part (at the right) : sprigns with MBDyn (with total joint)
Hi. Since my last answer, some things happened. Right now, on the
website you can find MBDyn 1.3.15, where the framework for tight
interaction with external solvers was further developed. Right now, the
external solver can actually be a python script, and you can have access
to the nodal kinematics in python arrays of nodal data, and set nodal
forces and moments in other python arrays, that can be sent back to MBDyn
in one call. I'll post an example, and document things a bit. The whole
thing is part of a project that's currently under development, so it
should be considered rather experimental (in the sense that it's subjected
to changes before things freeze). I'm posting an example helicopter rotor
that receives (constant) forces from a python script. I'm sure you'll be
able to modify it accordingly. From
run "simplerotor_ext" with MBDyn 1.3.15, and run simplerotor.py. You
should replace the contents of the simplerotor.py with forces communicated
from your FEM solver, and use the kinematics transmitted by MBDyn to
define FEM boundary conditions. Probably, more sophisticated couplings
are possible, we're just at the beginning of experimenting with this code.
The basics of the communication element are already documented in the
input manual; however, the interface is not, and you'll need to look at
the sample code to find out what it does. I'll document the API (both in
C and in python) not earlier than next week, as I'm on a (long) trip right
now, so you'll need to be patient.
Hope this helps. Cheers, p.
> Pierangelo Masarati <masarati at aero.polimi.it>
> 05/02/2010 16:58
> Romuald NORET <romuald.noret at cdr.hutchinson.fr>
> mbdyn-users at mbdyn.org
> Re: [MBDyn-users] Finite element coupling
> Romuald NORET wrote:
>> I am wonderdering if it is possible to make a coupling between MBDyn and
>> finite element software, for structural analysis.
>> It is possible and if it is this case, do you have an example?
> Not sure what you exactly mean, by coupling. Right now, you have many
> options, at different levels.
> 1) you can import Component Mode Synthesis elements (the "modal" joint)
> 2) you can have MBDyn talk to an external solver by sending "measures"
> (using the stream output element) and reading "controls" (using the
> stream driver), provided the other solver talks MBDyn's protocol (which
> is pretty simple). Somebody did it in Python to talk to Code Aster (I
> don't have the code, but we can ask, or redo it from scratch; the whole
> thing is similar to what Doug Baldwin used animate models in Blender
> run-time). This implements a "loose coupling" scheme, where MBDyn and
> the external solver independently solve the respective problems and
> communicate each other's results. In some cases, this may result in
> unstable couplings, much like you would have when using explicit
> integration schemes.
> 3) in 1.3.11 there are provisions for "tight" couplings in a scheme
> where MBDyn outputs motion to and read loads from an external solver;
> the two solvers can iterate in a staggered manner, in order to guarantee
> that they converge simultaneously. This is now working for sure in case
> of CMS models; it should also work for node sets, although it's not
> thoroughly tested. Of course, the other codes need to be able to read
> and write data according to MBDyn's format. We provide an open format
> for data exchange via ASCII files and library calls for inter-process
> communication using UNIX sockets. Adding built-in supports for
> different formats should be straightforward. We did it to communicate
> with FOI's EDGE using EDGE's built-in file format.
> Does this help?
> Cheers, p.
More information about the MBDyn-users