OpenFOAM function object crashes at the end of the simulation due to setting deltaT to zero

Official adapters and tutorials
,
1

Hello

I am using OpenFOAM-adapter-v1.3.1. I think there is an issue with the adapter at the end of the OpenFOAM simulation when the simulation (coupling) finishes and the function objects get triggered one last time.

---[precice]  Reached end at: final time-window: 5000, final time: 0.5
---[preciceAdapter] The coupling completed.
---[precice]  Close communication channels
---[preciceAdapter] The simulation was ended by preCICE. Calling the end() methods of any functionObject explicitly.
---[preciceAdapter] Great that you are using the OpenFOAM-preCICE adapter! Next to the preCICE library and any other components, please also cite this adapter. Find how on https://precice.org/adapter-openfoam-overview.html.
forces vocalFoldForces write:
    Sum of forces
        Total    : (0.03076961 -0.0007374726 -3.863188e-06)
        ...

I am using fixed timestep, so the following function gets called by the adapter

 // Adjust the timestep, if it is fixed
    if (!adjustableTimestep_)
    {
        adjustSolverTimeStepAndReadData(); // <-----
    }

    // If the coupling is not going to continue, tear down everything
    // and stop the simulation.
    if (!isCouplingOngoing())
    {
        adapterInfo("The coupling completed.", "info");
        ...

In the adjustSolverTimeStepAndReadData() function the timestep gets set zero

else if (timestepSolverDetermined - precice_->getMaxTimeStepSize() > tolerance)
    {
        // In the last time-step, we adjust to dt = 0, but we don't need to trigger the warning here
        ...
        timestepSolver_ = precice_->getMaxTimeStepSize();
    }
const_cast<Time&>(runTime_).setDeltaT(timestepSolver_, false);

Which I assume is fine for most of the function objects, but Curle function object calls fvc::ddt(p) which uses deltaT in denominator and as a result causes a crash.

...
surfaceFieldValue volumeFlowRateOutlet write:
    total faces   = 1128
    total area    = 0.0001

    sumMag(outlet) of phi = 0.000196024

[4] [stack trace]
[4] =============
[1] [stack trace]
[1] =============
...
==== backtrace (tid:  14466) ====
 0 0x000000000003fc30 __GI___sigaction()  :0
 1 0x000000000008d02c __pthread_kill_implementation()  ???:0
 2 0x000000000003fb86 __GI_raise()  :0
 3 0x000000000003fc30 __GI___sigaction()  :0
 4 0x0000000001f43ba4 Foam::operator/<double>()  ???:0
 5 0x00000000006e5bbc Foam::operator/()  ???:0
 6 0x0000000001c74c06 Foam::fv::backwardDdtScheme<double>::fvcDdt()  ???:0
 7 0x0000000001d14162 Foam::fvc::ddt<double>()  ???:0
 8 0x000000000063e958 Foam::functionObjects::Curle::execute()  ???:0
 9 0x00000000006b670f Foam::functionObjects::timeControl::execute()  ???:0
10 0x00000000006a9497 Foam::functionObjectList::execute()  ???:0
11 0x00000000006c8309 Foam::Time::run()  ???:0
12 0x000000000042d44f main()  ???:0
13 0x000000000002a610 __libc_start_call_main()  ???:0
14 0x000000000002a6c0 __libc_start_main_alias_2()  :0
15 0x0000000000430e45 _start()  ???:0
2

@marhatom which preCICE version are you using? There were issues with time step sizes reaching zero in some releases.

3

I am using preCICE version 3.4.0

4

@Makis this sounds more like this Curle function is called after the last time step, expects the fixed time step, but finds the 0, set by preCICE and fails.

5

The first time reading through this (too fast), I did not realize this was involving another function object that needs the dt. We never considered interoperability with such function objects that consume the dt, so this is very much a blind spot.

I opened an issue and I will try to address it in the next days: Setting the time step size at the end of the simulation · Issue #415 · precice/openfoam-adapter · GitHub

@marhatom any minimal working example or anything else to add since you first opened this thread?