[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
Mon Feb 9 12:50:49 CET 2015


Dear All,

I am replying to give everyone my feedback and to show a simple example 
(see attachment) focused on the imposition of the timestep by a code 
written in FORTRAN. I am open to any suggestion/correction/improvement.

I have applied P. Masarati's suggestion to impose a variable timestep 
from an external code. My CFD code is written in FORTRAN so I had to 
call a function written in C to communicate easily through the UNIX socket.

All seems to work well except that the setting of the timestep takes 
place at the third temporal iteration, whereas I expected that it will 
be applied at the second timestep. It is a minor problem and I am OK 
with this. However if someone finds a mistake in the code, I will be 
glad to know it.

Sincerely,

Yoann





Le 23/01/2015 17:53, Yoann Robert a écrit :
> 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.
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ext_var_ts.tar.gz
Type: application/x-gzip
Size: 1828 bytes
Desc: not available
URL: <http://mail.mbdyn.org/pipermail/mbdyn-users/attachments/20150209/2e324539/attachment.bin>


More information about the MBDyn-users mailing list