I am using adaptive time stepping scheme in OpenFOAM which is being coupled to another solver written in Nutils. I am using serial implicit coupling scheme. Nutils uses the time step adapted by OpenFOAM. For this functionality I am using <time-window-size value="..." method="first-participant"/>
My question is that, when OpenFOAM runs, what I expect is that, it should adapt a time step and then do coupling iterations, until it is converged for a current time window; it should not adapt the time step during the coupling iterations. Rather what it does, it keeps on adapting the time during the coupling iterations and due to this, coupling time window also changes which for a particular time window doesn’t make sense for serial implicit coupling scheme in my understanding. Please correct me if I am wrong.
So simply speaking, the required behavior I expect from <time-window-size value="..." method="first-participant"/> when using serial implicit coupling scheme:
1- OpenFOAM adapts the time step, Nutils uses that time step.
2- Both participants uses that time to sub-iterate until a relative convergence measure is achieved on the data we want to accelerate on. During these iterations, OpenFOAM shouldn’t adapt the time step rather use the same which it adapted for the current coupling window.
3- When the relative convergence measure is achieved on the data we want to accelerate on and the time window is completed, then OpenFOAM should adapt the time step again.
Is there a way available in OpenFOAM’s adpater to get this kind of functionality?
I am attaching the log files from OpenFOAM and Nutils, if anyone wants to look at it.
This is not a feature that we ever considered in the OpenFOAM adapter (and probably not any other adapter), so I am not sure what is actually happening here.
To summarize, you have:
implicit coupling
adaptive OpenFOAM time step size
coupling time window always set to the OpenFOAM timestep size (with method="first-participant").
I assume that, in every time step, OpenFOAM:
Computes a new time step size, based on the CFL criteria
Solves and gives this time step size to preCICE, which triggers immediate coupling
Reads new values on the interface, which affect the next time step size as well
As the coupling has not converged, OpenFOAM reads a checkpoint
At the last step, even if the adapter reloads the previously computed time step size, OpenFOAM itself will anyway recompute the time step size, which the adapter will then always compare to infinity (from preCICE) and not modify it.
The only way I can see to “fix” (?) this in the adapter would be to not only compare to the preCICE dt, but also to the OpenFOAM dt at the beginning of the coupling time window. However, this sounds too perplexed to be a good solution. Sounds more like something to be controlled by preCICE itself.
@uekerman what should be the intended behavior when combining implicit coupling + first-participant + adaptive solver dt? Has this already been defined?
AFAIK, first-participant uses the adaptive timestep size in every iteration. Freezing this timestep size to the value of the first iteration is not sth that preCICE already supports, but should not be too complicated to implement I guess.
This is clear. But is it intended that the coupling time window size adapts during a coupling time window (different for every iteration)? Do you maybe know of any similar examples in the past? I guess this is a niche feature at the moment.
But is it intended that the coupling time window size adapts during a coupling time window (different for every iteration)?
Yes, this is what preCICE does right now. I guess this is the more natural way here. Keeping it fixed to whatever the first iteration suggested is also a bit random.
Do you maybe know of any similar examples in the past? I guess this is a niche feature at the moment.
Hi
I understand what you said. But the problem is I am simulating a case where for 3ms pressure is imposed at the inlet and then it is put to zero. Now I want to observe the behavior between these 3 milli seconds and then in the long term. Now the convergence is achieved for first time window after 3ms which makes it impossible to observe the correct behavior during this time (You can see the log files attached). For long term it is possible because convergence is achieved after just one Aitken iteration. That’s why I was looking for method to fix the size for a specific coupling window until convergence is achieved.