I’m trying to improve the overall compatibility of the MBDyn adapter. In particular I’m working on the time step management. Up to now all my simulations were based on the idea that MBDyn has the same time step of the coupling and possibly the fluid solver performs subcycling. That is, the MBDyn timestep is fixed. Nevertheless it is possible to define the current time step in MBDyn and I’m using this feature within the adapter.
The following snippet contains what I’m doing with the timestep. This works if I have mdyn_dt == precice_dt (as before) but it doesn’t work if mbdyn_dt < precice_dt. Besides, I’m not sure that I can roll-back more than one time-step computation if the simulation does not converge at the end of a coupling time-step.
// Start coupling:
while (interface->isCouplingOngoing()){
if(interface->isActionRequired(actionWriteIterationCheckpoint())){
interface->markActionFulfilled(actionWriteIterationCheckpoint());
}
// read forces from interface
if (interface->isReadDataAvailable()) {
interface->readBlockVectorData(readID, vertexSize, vertexIDs, adapterReadVector);
}
current_dt = std::min(precice_dt, mbdyn_dt);
MBDynAdvance(); // compute and update displacements and forces
if(interface->isWriteDataRequired(current_dt)){
interface->writeBlockVectorData(writeID, vertexSize, vertexIDs, adapterWriteVector);
}
// advance
precice_dt = interface->advance(current_dt);
if(interface->isActionRequired(actionReadIterationCheckpoint())){
// timestep not converged
// reloadOldState(); // set variables back to checkpoint
interface->markActionFulfilled(actionReadIterationCheckpoint());
conn->putForces(false); // tell MBDyn to repeat step
}else{
// timestep converged
conn->putForces(true); // tell MBDyn to go to the next step
}
}
On the other hand I would like to get rid of “if(interface->isWriteDataRequired(current_dt))” and “if (interface->isReadDataAvailable())” as they are on one side deprecated but they are described, as far as I understand, necessary for the time step management.
I am not specifically testing some sub-cycling in FSI (I am not even sure that I could handle this feature), my goal is to make the adapter as compliant as possible with the preCICE capabilities. Up to now, I simply configure the structural simulation with the same time-step of the coupling (in particular one has to put the same delta-t of the coupling in the MBDyn configuration file, which is not ideal). I’ve been testing the sub-cycling only in the fluid participant (driven by the Courant number).
So any suggestions on how to implement time-step management is greatly appreciated.
Only became aware of this now. Did you find a work-around in the meantime? I think it would be extremely helpful, if you could write a quick update here.
Below are my thoughts on this topic.
The following part sounds a bit risky to me:
Nevertheless it is possible to define the current time step in MBDyn and I’m using this feature within the adapter.
Does this mean you are using the setting method="first-participant" in your configuration? This has the following implications:
I assume MBDyn has to always go first and you only support serial coupling, because this is a requirement for having the first participant define the time window size.
The time window size is set by MBDyn through advance(MBDyns_time_step). Note that it is not possible for MBDyn in this case to perform subcycling, because preCICE will always terminate the window at the end of the time step MBDyn is performing. The other participant (second participant, probably non-MBDyn?), however, may use subcycling, if other_participant_time_step < MBDyns_time_step
Please note that the restriction mentioned above is a shortcoming of the preCICE API that (I think) we cannot really circumvent easily: If we would like to support subcycling + first participant setting the time step size, we would need a method precice.setTimeWindowSize(MBDyns_time_window_size) to let the first participant explicitly set the time window. Supporting this is not trivial and there are many technical challenges. Feel free to open a feature request, if you really need this feature.
Hi @BenjaminRodenberg ,
in the end I came up with a solution that can probably be improved. At the moment I am able to deal with the following cases:
the easy one: MBDyn runs with a fixed time-step (written in its config file) and it is up to the user to set it equal to the preCICE time-step. This is how I handled it at the beginning.
make the current time step configurable: with a proper set of statements in the MBDyn config file, you can define the current simulation time-step at each cycle.
Now I can enable this last feature in the adapter and it works as follows:
in the adapter config file I set the default time-step of the MBDyn simulation (mbdyn_dt).
at each iteration I check precice_dt and mbdyn_dt
I can have:
mbdyn_dt = precice_dt: this is the MBDyn simulation time-step
mbdyn_dt > precice_dt: precice_dt is the next simulation time-step
mbdyn_dt < precice_dt: I should probably do sub-cycling but I can’t (as far as I know) roll back more than 1 MBDyn execution, so I still use precice_dt with a warning to the user
I haven’t had the need to perform more structural time-steps than fluid time-steps, so for the moment it works.
Your post made me remind of a chat that we had during the last workshop, where you mentioned the method “first-participant”. This was something that some colleagues of mine, working with MBDyn and Dust would be interested in. This might a topic for further integration and improvement, because I am not sure if at the moment it would work.
Caudio