Allow early exit in OpenFOAM-OpenFOAM coupling

Official adapters and tutorials
1

Hi,

I’m using preCICE v2.3.0 and the OpenFOAM adapter v1.0.0 to couple buoyantSimpleFoam and laplacianFoam (OpenFOAM v2106). In the laplacianFoam case I use the runTimeControl function object to terminate the simulation if the change of the average temperature of the solid is below a threshold.
Now I have the following problem: If the runTimeControl function object detects that the change of the average temperature of the solid is below the defined threshold, I get the following output

---[preciceAdapter] The coupling timestep completed. Writing the updated results.
--> FOAM Warning : 
    From void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 17
    Warning in the preCICE adapter: 
The solver exited before the coupling was complete.


---[precice]  relative convergence measure: relative two-norm diff of data "Temperature" = 0.00e+00, limit = 1.00e-05, normalization = 5.09e+04, conv = true
---[precice]  All converged
---[precice]  Time window completed
---[precice]  iteration: 1 of 30, time-window: 12, time: 11 of 2000, time-window-size: 1, max-timestep-length: 1, ongoing: yes, time-window-complete: yes, write-iteration-checkpoint 
---[preciceAdapter] The coupling timestep completed. Writing the updated results.
End

---[precice]  Implicitly finalizing in destructor
---[precice]  Synchronize participants and close communication channels

and the laplacianFoam simulation ends and the last results of the last time step are written. This corresponds to my desired behavior. But the buoyantSimpleFoam simulation is still running and (I think) waiting for results from laplacianFoam, which it obviously won’t get.
What I want is that also buoyantSimpleFoam terminates and the last results of the last time step are written.

At the beginning of the log file the following is written:

---[preciceAdapter] Setting the solver's endTime to infinity to prevent early exits. Only preCICE will control the simulation's endTime. Any functionObject's end() method will be triggered by the adapter. You may disable this behavior in the adapter's configuration.

Is this the solution for my problem? If yes, how can I disable this behavior? I’ve seen that there was a switch preventEarlyExit_ in earlier versions of the OpenFOAM adapter but it doesn’t exists in v1.0.0.

Thank you!

2

Hi @exkroy
youre use-case is a bit uncommon in the preCICE sense, because usually preCICE steers (and terminates) the coupled simulation. This was also the reason we ‘removed’ the solver exit from the OpenFOAM solver.

There is no predefined option in order to change the endTime behavior of the coupled solver. If you really want to get rid of this behavior, you could simply remove the following few lines from the adapter

However, I guess this won’t fix your problem unless you ‘measure’ on both sides the same behavior and exit the simulation at the same time on both sides. The preCICE-native way would be to let preCICE decide on the convergence of the coupled simulation (using relative or absolute-convergence-measure). What is your motivation to use your own convergence criterion? The most simple solution for you would probably be to translate the solver convergence criterion into a preCICE convergence criterion.

3

Hi @DavidSCN
thank you for your reply!
How can I use relative-convergence-measure or absolute-convergence-measure to end the whole simulation? I only know how to use it as a measurement for convergence of an implicit coupling loop as described here: Coupling scheme configuration | preCICE - The Coupling Library.

4

Based on your description I would assume that you try to couple a steady-state scenario. Is this the case? If yes, the idea would be to select the max-iterions tag of an implicit coupling very high and perform just a single time-step of an implicit coupling. preCICE will of course abort in case the convergence criteria are met.

5

Yes, it is a steady-state simulation.
I had not thought of this possibility. I’ll give it a try. Thank you!

6

Maybe for the sake of completeness: if your steady-state solution is far away you can still combine this with subcycling i.e., selecting smaller time-step sizes in your solver compared to preCICE.