Deadlock during finalization

Dear all,
I am using preCICE 1.5.2 to couple my fluid and structural solver on Ubuntu18.04. I met with a strange problem and I don’t know how to solve it. preCICE finished coupling and stopped normally when max-time is 0.031and tilmestep-length is 0.001. However, the terminal stoped at t =0.032 and there was no hint of error when max-time is 0.032. It just stopped and there wasn’t any change in the screen for a long time as shown in the picture. I have tried several times but it failed at the same place.


Can anyone give me some advice?
Thanks!!
Jun

Welcome, @jun_leng!

I see that you are coupling OpenFOAM. Are you using our adapter or have you coupled a specific solver yourself? I assume something is going wrong in the order of calling preCICE. Can you describe your sequence?

Have you already seen our adapter example?

Hi~
I have seen the adapter examples. I am using my own adapter of OpenFoam because I need to add some codes in pimpleFoam and it is easier for me to add preCICE in the codes directly. currently, I am using the serial-explicit coupling method to couple OpemFoam with MBDyn. The coupling went well before 0.031s. But it stopped computating at t=0.032s.


And I noticed that the log file of MBDyn showed it had stopped at t=0.029s while preCICE showed it arrived at t=0.031s. I don’t know why it happened. I think there is something wrong when MBDyn received the external forces.

And this is the config.xml file.

And I noticed that the log file of MBDyn showed it had stopped at t=0.029s while preCICE showed it arrived at t=0.031s.

By “stopped” you mean exited with error?

Keep in mind that you are using a serial coupling, where as “first participant” you have MBDyn and “second” you have OpenFOAM. I see this in your config:

<coupling-scheme:serial-explicit>
  <participants first="StructureSolver" second="FluidSolver">

So, the first participant goes up to t=0.029\mathrm{s} and crashes at the end of it (has it already called advance() for t=0.030\mathrm{s}?) Shortly afterwards (but strangely not at the next timestep), the second participant hangs, while it should also error with “End of file”.

I suspect the following:

  • Something wrong in one of the two adapters (not sure what at the moment), especially the sequence of calls
  • A compatibility issue (do both solvers use the same MPI? I had strange hangs like this once and that was the cause)

Hi~
“stopped” means both terminal neither advanced nor existed and the screen didn’t change as the picture shows. The left one is OpenFoam and the other one is MBDyn. No error or hints showed on the screen.


From the right terminal (MBDyn) I notice that the preCICE goes up to 0.032s. But the log file of MBDyn shows it stopped at 0.029s.
I have changed “first participant” to OpenFOAM, but the results didn’t change.
I didn’t use parallel computing. What do you mean both solvers use the same MPI? sorry, I am not familiar with MPI.

It shows as follows when I pressed control+C to force the coupling to stop running.

Could you switch on debugging output as suggested in the first example here? For this you need to build preCICE in Debug mode, cmake [...] CMAKE_BUILD_TYPE=Debug.
There is a sychronization step in finalize, both solvers wait for each other. What you describe sounds like a standard deadlock.
I guess that the problem is that you don’t call finalize at the right moment (as soon as ongoing==false) is one of both adapters.