OpenFOAM-CalculiX: Timestep Error

Hello
I was running a coupled pipe case between OpenFOAM and CalculiX however, after running for some time, I received the following error, which stopped coupling:

Adapter writing coupling data…
Adapter calling advance()…
—[precice] ^[[31mERROR: ^[[0m advance() cannot be called with a timestep size of 0.

Please find attached log files for both OpenFOAM and CalculiX
calculix.out (3.4 MB)
foam.out (4.7 MB)

Would appreciate any help

This error comes from the CalculiX side. There we couple via iterations and not by the actual CalculiX timestep and it seems like your CalculiX simulation reached its timestep and the next increment for the iteration would be 0, which legitimatly conflicts with precice, that doesn’t accept 0 as a timestep. Can you maybe share your input files for CalculiX and precice?

1 Like

Sure.
precice-config.xml (2.6 KB)
tube.inp (482 Bytes)

As @mattfrei mentioned, this seems to be coming from the CalculiX side. Looking at the output:

Adjusting time step for transient step
precice_dt dtheta = 0.010000, dtheta = 0.000000, solver_dt = 0.000000
Adapter reading coupling data...
Reading FORCES coupling data with ID '3'. 
Adapter writing checkpoint...
 increment 101 attempt 1 
 increment size= 0.000000e+00
 sum of previous increments=1.000000e-02
 actual step time=1.000000e-02
 actual total time=1.000000e-02

The second line corresponds to: calculix-adapter/PreciceInterface.c at 6fdce488932dd9f4c035b607008566617e5c44e0 · precice/calculix-adapter · GitHub

    printf("Adjusting time step for transient step\n");
    printf("precice_dt dtheta = %f, dtheta = %f, solver_dt = %f\n", sim->precice_dt / *sim->tper, *sim->dtheta, fmin(sim->precice_dt, *sim->dtheta * *sim->tper));
    fflush(stdout);

    // Compute the normalized time step used by CalculiX
    *sim->dtheta = fmin(sim->precice_dt / *sim->tper, *sim->dtheta);

    // Compute the non-normalized time step used by preCICE
    sim->solver_dt = (*sim->dtheta) * (*sim->tper);

If I understand correctly, CalculiX (or the CalculiX adapter) works in terms of “increments” (could tper mean time per increment?). Or at least that’s how I understand the “normalized time step”. I suspect that something is going wrong with this normalization, leading CalculiX to do zero increments / give a zero dt to preCICE.

dtheta is defined in the solver nonlingeo_precice.c as: dtheta = (*tinc) / (*tper). The solver already seems to be trying to catch a similar problem:

  if ((dtheta <= 1.e-6) && (*iexpl <= 1)) {
    printf("\n *ERROR in nonlingeo\n");
    printf(" increment size smaller than one millionth of step size\n");
    printf(" increase increment size\n\n");
  }

What happens if you modify the *STEP, INC=1000000 in tube.inp? Probably by decreasing it.

It is generally strange that the structure solver asks for smaller time steps than the fluid solver.

In CalculiX Input File under

  *DYNAMIC,DIRECT,NLGEOM

you specify the (initial) increment size with the first argument and the time period of the CalculiX step with the second one. In your case:

  0.0001, 0.01

With the keyword DIRECT you keep the increment size fixed.
Now the problem is that the CalculiX Timestep is finished after 100*0.0001s(increment size)=0.01s(timeperiod of the timestep). And as the CalculiX adapter doesn’t support more Timesteps in CalculiX it just takes the increments of this one timestep and an error occurs if the increment is legitimately set to 0, which is the case, when the time period is reached.

I guess the solution for your case to run until 1s would be to specify the time period of the timestep as 1, leading to the following lines in your CalculiX input file:

  *DYNAMIC,DIRECT,NLGEOM
   0.0001,1.0

Maybe you can try that.

1 Like

That was it! Thank you so much!
I do have another quick question; if I want my simulation to restart from latest time, do I just have to change the startTime to latestTime in OF or would I have to change something in the precice-config?

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

You don’t need to modify anything in the precice-config.xml. See How can I restart a coupled simulation? and Restarting coupled FSI simulation with preCICE

Since this is a different question, let’s continue in a new thread if you still want to discuss it.