We have been using an explicit coupling of a third party solver called blastFOAM and a FEA solver until recently. Our recent attempts to switch to implicit coupling resulted in some fatal errors (see image below) at the very beginning of the coupled run. Upon looking further, I realized that the error happens inside the ‘writeCheckPoint()’ routine in the file Adapter.C of the OpenFOAM adapter. Specifically, it happens when the surface scalar fields are being stored as part of checkpointing.
I have contacted the blastFOAM support team regarding this and asked if/whether blastFOAM follows the same structure as the official OpenFOAM solvers. The response I received is that the use of fields are all the same, but typically there are no implicit matrices solved. They are also wondering what is needed to implement implicit coupling? Unfortunately, I am not familiar with OpenFOAM code structure and do not know how to advise them on what changes are needed to be able to support implicit couplings. Obviously, I know that the solver needs to store checkpoints of the state but what is not clear to me is if/whether that is done by making a call to an API in the OpenFOAM library? If yes, what would that be?
In summary, are there instructions somewhere that a third party solver like blastFOAM must follow to be able to support implicit couplings through the standard OF adapter? Any response would be appreciated.
This is a good point that we currently don’t really document. The closest documentation page is this one (which does not really help). However, you may find more information in my master’s thesis (for example, in section 2.2.7). You can read how checkpointing works in section 5.3.4.
I guess we don’t use the same terminology here and they probably understood something different with the term “implicit coupling”. OpenFOAM does not know whether it is participating in an implicit coupling scheme, it is only forces to go back in time, reload some fields, and compute a few time steps again.
Nothing special is needed on the solver side to be compatible with implicit coupling. If it follows the same structure as an official solver, then it registers all its objects in the objects registry. For checkpointing, we look for different common types of fields in the objects registry (e.g., volScalarField, see full list here (yes, I know, this is not very beautiful code, sorry )). We manually store these in our own copies inside the adapter and, if preCICE tells the adapter to reload a checkpoint, we copy them back.
From this screenshot, I don’t really inderstand what could be going wrong, as it does not contain any actual error message. As I explained on Gitter, I believe that you are using an OpenFOAM Release build. This would explain the at ??:? parts of the log.
Hi @Makis,
Since my tests always crash due to ERROR: advance() cannot be called with a timestep size of 0 on the fluid side (OpenFOAM), but our solid solver converges well, I wonder if I could use OpenFOAM adapter with checkpoint(implicit coupling) while my solid solver still use explicit coupling?
This is not possible. If you ask preCICE to execute an implicit coupling, then both solvers will need to reiterate. You could hack your solid solver to ignore checkpointing and not recompute anything, but then the coupled simulation would probably not converge, as the flow solver would not get correct feedback from the solid solver.
)). We manually store these in our own copies inside the adapter and, if preCICE tells the adapter to reload a checkpoint, we copy them back.