[MBDyn-users] Coupling of MBDyn with an external code using a variable timestep (recomputed at each temporal iteration)

Yoann Robert yoann.robert at ec-nantes.fr
Fri Jan 23 17:53:11 CET 2015


Thank you very much for your quick and detailed answer. I will test your 
solution as soon as possible.
Have a nice weekend.

Yoann



Le 23/01/2015 16:31, Pierangelo Masarati a écrit :
> On 23/01/2015 12:46, Yoann Robert wrote:
>> Dear developers and users of MBDyn,
>
> Hello.
>
>>
>>
>> A colleague of mine has already coded a tool coupling MBDyn and the CFD
>> code of our team. His simulations were launched with a constant
>> timestep. In my case, the physics of the problem forces me to use a
>> variable timestep, depending on the Courant number, and which is
>> recomputed at each temporal iteration in the CFD code. So my CFD code
>> must impose the timestep value to MBDyn.
>>  From this, several questions comes to mind.
>>
>> 1) In the current version of MBDyn, is this possible to do such a 
>> coupling?
>> 2) If this is not possible, is it planned in the next versions? How 
>> soon?
>> 3) If it is not the case, are the modifications of the source code of
>> MBDyn quite easy to do by myself? And could you tell me in which files
>> or functions this modifications would take place?
>
> It is possible, although not straightforward.  Basically, you need to 
> use the "external * force" element to communicate kinematics and 
> forces between the two solvers and, at the same, a stream file driver 
> to communicate the time step from your solver to MBDyn.  At this 
> point, you can set the time step received through the stream file.
>
> See the code snippet below:
>
> # ...
>
> begin: initial value;
>         initial time: 0.;
>         final time: 10.;
>         time step: 1.e-3; # the initial time step
>
>         set: const integer TIMESTEP = 1;
>         strategy: change, postponed, TIMESTEP; # changes the time step 
> as specified by the drive caller labeled TIMESTEP, whose definition is 
> postponed (this is simply a placeholder)
>
> # ...
>
> end: initial value;
>
> begin: nodes:
>     # define nodes ...
> end: nodes;
>
> begin: drivers;
>     set: const integer INPUT = 200;
>     file: INPUT, stream,
>                 stream drive name, "TS_DRV", # irrelevant but needed
>                 create, yes,
>                 path, "./mbdyn.timestep.sock", # or use port
>                 1;      # one channel: the time step
>
>         drive caller: TIMESTEP, file, INPUT, 1; # replace placeholder 
> with file driver
>
>     # ...
> end: drivers;
>
> begin: elements;
>     # put here the external force element and other elements ...
> end: elements;
>
>>
>>
>>
>>
>> EXTRA QUESTION:
>>
>> This question is about something less important but it would allow me to
>> lighten my input files, especially the drives in my joint elements.
>> I browsed the documentation and I learned we can define some "plugin
>> variables" from the nodes or from the elements, using directly the data
>> accessible through the node/element in question, such as
>>
>> set: integer NODENAME = 1000;
>> # the node must exist
>> set: [node,VARNAME,NODENAME,abstract,string="xP"];
>>
>> or
>>
>> set: integer ELEMNAME = 1000;
>> # the joint must exist
>> set: [element,VARNAME,ELEMNAME,joint,string="Fz"];
>>
>> Unfortunately, it does not seem to me that the definition of more
>> complex time-dependent variables is allowed. For instance, supposing
>> that the three following constants are defined, such a definition is not
>> possible (or a least not in this way):
>>
>> set: integer NODENAME = 1000;
>> # the node must exist
>> set:
>> [node,VARNAME,NODENAME,abstract,string="xP*const_length*const_time*const_mass"]; 
>>
>>
>>
>> It does not seem more likely that a definition of a time-dependent
>> variable also depending on data from multiple nodes and/or elements is a
>> possibility.
>>
>> Did I miss something or is it the case in the current state of the code
>> ? I know I may be too greedy... :-)
>
> The naming is a bit confusing.  I understand what you're trying to do 
> is a sort of a function, i.e. you want to associate a variable with a 
> function that is evaluated whenever the variable is dereferenced.  
> This is not possible.  The "string" bit of the so-called plugin 
> variable holds the name of the value (it is called private data) that 
> is to be set for the plugin variable. It cannot be an expression (it 
> has nothing to do with the "string" drive caller, to be clear).
>
> You can implement something like that using drive callers themselves; 
> to follow on with your example, making it a little bit more complicated,
>
> # define the drive
> set: const integer DRIVENAME = 0;
> set: const integer NODENAME1 = 100;
> set: const integer NODENAME2 = 200;
> drive caller: string,
> "(model::node::structural(NODENAME1,\"xP\") + 
> model::node::structural(NODENAME2,\"xP\"))*const_length*const_time*const_mass";
>
> # use it
> string, "10.*model::drive(DRIVENAME, Time)";
>
> NOTE: this should work as intended.  However, I just realized that if 
> you built MBDyn with multithread support, it deadlocks because of 
> inadequate mutex protection of the string parser.  You need to compile 
> with thread support disabled, or avoid nested strings.
>
> Sincerely, p.
>



More information about the MBDyn-users mailing list