Simulation gets stuck at same time window

Using preCICE
, ,
1

Hi there,
I’m trying to run an FSI simulation using OpenFOAM for the fluid and CalculiX for the solid, but for some reason my simulation consistently stops running at time window number 101 without any error message indicating why. I have tried two different sizes of timestep (0.001s and 0.005s) and both times the simulation stopped at timestep number 101. Any ideas? I’m using preCICE 2.2.0 and ccx-2.16, and have had the same problem using OF v1912 on a cluster and OF5 on a smaller computer
solid.log.log (694.8 KB)
fluid.log.log (626.9 KB)
precice-config.xml (2.4 KB)
Thanks!

2

Hi!

Just for some clarification. What does “stop” mean in your situation. Do both solvers hang without creating further output and you have to kill them manually or do both solvers terminate in some way?

3

Thanks for the reply, they both hang and I have to kill them.

4

Hi @rachaelesmith! Could you please also upload your CalculiX and OpenFOAM adapter configs?

5

preciceDict.txt (487 Bytes)
config.yml (224 Bytes)

6

And what is the end time of each solver?

7

You could simply add all input and log files that you had posted on Gitter + information that Makis asked about as this would help a lot.

Additionally, if you could run the simulation with a Debug build of preCICE and enable advanced logging, see the docs and there especially in the example section, to get more information about what preCICE does and in which operation preCICE is busy when the simulation hangs.

Also another question: Is the solution in the first 100 time steps meaningful?

8

fluid.log (2.8 MB)
solid.log (1.1 MB)
controlDict.txt (959 Bytes)
flap.inp (345 Bytes)

These log files were generated when I set the logging according to the example of debugging where initialization hangs.

<log>
    <sink type="stream" output="stdout"  filter= "(%Severity% > debug) or (%Severity% >= debug and %Module% contains SolverInterfaceImpl) or (%Severity% >= debug and %Module% contains partition) or (%Severity% >= debug and %Module% contains PointToPointCommunication)"  enabled="true" /> 
</log>

The simulation hangs after ‘Advance coupling scheme’ in the fluid log file, and looking at the rest of the file I assume that the next line should be 'Map read data “Displacement” to mesh “Fluid-Mesh” '?

The end time is 20 in OpenFOAM and 10 in CalculiX. The solution looks as I had expected for the first 100 timesteps.

9

To me it looks like the Calculix solver hangs when writing its checkpoint for some reason. The fluid solver is already at the next coupling step ready to advance the coupling.

I am not sure if you can get more verbose output out of the adapter. Maybe one of the Calculix experts knows more about that.

10

I am not sure what is going wrong, but to document a few observations:

  • OpenFOAM runs in parallel (4 ranks), CalculiX in serial. Communication is via sockets.
  • Both sides have already completed a few time windows and iterations.
  • While CalculiX completes the iteration and moves to writing a checkpoint:
    iteration: 1 of 50, time-window: 101, time: 0.5 of 10, time-window-size: 0.005, max-timestep-length: 0.005, ongoing: yes, time-window-complete: yes, write-iteration-checkpoint
    OpenFOAM is in advance() in the first iteration of Time = 0.505 (there is no similar detailed message on the OpenFOAM side).

What happens if you run the same case in serial?

Also, what happens if you use a different coupling time step size?

11

The same thing happened when I ran the case in serial.

When I tried a timestep of 0.001, the simulation stopped at time = 0.1 i.e. at time window 101 again

12

solid.log (2.2 MB)

I re-ran the simulation with filter= “(%Severity% > trace)” in the logging, which seems to have finally produced some sort of error message in the solid.log file:

Adapter writing checkpoint…
*ERROR: max. # of increments reached

(0) 18:35:38 [utils::Events]:59 in stop: e[0mStopped event solver.advance
(0) 18:35:38 [utils::Events]:59 in stop: e[0mStopped event _GLOBAL

13

This is definitely getting interesting!

The error you get is by CalculiX. What follows is just exiting advance().

I find the following on the Mecway forum:

Increased time period to 0.05 s. It won’t actually solve all the way to 0.05 s but this is to get around the following problem. When CCX stops with

*ERROR: max. # of increments reached

it doesn’t mean there’s anything wrong with the model, but just that CCX was told (by Mecway) to stop after a certain number of increments, which is Time period / Time step . In models where the increment size gets automatically reduced and not increased, it can hit that limit.

In other words, CalculiX does not really realize that we overwrite its timestep size and it thinks that it already completed all of its timesteps. An easy workaround would be (I guess) to greatly increase the end time of CalculiX. preCICE will anyway tell CalculiX to stop at the end.

But this error then is CalculiX-specific and it is strange that it did not appear before.

14

Solved it at last! Increasing the end time in CalculiX didn’t help, but setting INC to a very large number (I put INC=1000000) after *STEP in the input file did.

Thanks for helping me with this!

4 Likes
15

Nice to hear that! :tada: We should document this on the CacluliX adapter configuration page. If you want, feel free to suggest a change on GitHub!

16

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