Thank you for the follow-up! I unfortunately fail to test this at the moment (not even the previous state). While it previously worked on my system, I now end up always getting a floating-point exception during the preCICE initialization.

The dummy-turbine case works, other OpenFOAM-based tutorials work, I have tried older versions of preCICE, and rebuilt most of my stack.

In the meantime, have you tested if this runs?

I did test the changes and at first everything worked, but looking closer into it I found the following when running the cfd-turbine case:

• When I start OpenFAST first and OpenFOAM second, the simulation runs without errors and produces reasonable results.
• When I start OpenFOAM first and OpenFAST second, the solver values in OpenFOAM explode from the second time step onward. I don't get any errors upon initialization, but soon after the courant number and the time step error printed in the pimpleFoam log are unreasonably high. The simulation crashes after a few time steps.
• I could also replicate the floating point exception on initialization you were mentioning. It happened although I started OpenFAST first, which usually works fine.

Between those runs I did not change any of the input parameters and cleaned the case files between each run. This pattern does not occur when the OpenFOAM library turbinesFoam is activated.

My current guess is that it has something to do with the way the force and velocity mesh are initialized in the OpenFAST adapter. However I did not investigate that yet. The code section related to that in src/openfast-adapter.cpp is:

For completeness, I am using the following software setup:

• OpenFOAM v2206
• OpenFAST v3.5.0
• preCICE v3.0.0 (v2.5.0-550-g586ac794) from the develop branch
• OpenFOAM adapter v1.2.3 + unreleased changes from the develop branch

I could also replicate the floating point exception on initialization you were mentioning. It happened although I started OpenFAST first, which usually works fine.

For me, it fails with the same initialization issue independent of which participant I start first.

My current guess is that it has something to do with the way the force and velocity mesh are initialized in the OpenFAST adapter. In any case, if a workaround like this is needed, let's document for now and fix as soon as we understand it.

Normally, it should not matter which participant starts first on the system. This would only be related to the initialization order in the coupling scheme.