Coupling crash readData(...) only long simulations

Using preCICE
,
1

Hi,
I am working on coupling one MATLAB simulation with two OpenFOAM simulations, running in an explicit-parallel scheme. We have a custom set of variables we couple and are running into a strange issue. When running coupled simulations for short times (1s simulated time), the simulations finish without any issues on both sides. However, when running longer simulations (200 or 500s), they run perfectly well until the last time step and in the final coupling, OpenFOAM writes the data and then waits for data from MATLAB. MATLAB crashes with the error:

"readData(...) cannot sample data outside of current time window.")

It seems like this error originates from ParticipantImpl.cpp:

PRECICE_CHECK(math::smallerEquals(relativeReadTime, _couplingScheme->getNextTimeStepMaxSize()), "readData(...) cannot sample data outside of current time window.");

Since this error does not appear for shorter simulations it can’t be an issue of the order of write(), read(), advance(), right?
To me it seems like there might be some numerical issue which only comes into play at longer run times, but I was not able to trace the error in the implementation of getNextTimeStepMaxSize().

Anybody got any ideas where to look?

Thanks and kind regards

David

2

Hi,

Which preCICE version are you using?

We had pretty much this exact problem with 3.0.0 and improved the situation in the following 3.1.0 release.

Best regards
Frédéric

3

Hi,
Yes sorry, I forgot to add this information. We are running two separate dockers right now. Ubuntu 22:04, one MATLAB r2024a + bindings 3.1.0 + preCICE 3.1.2 and one OpenFOAM v2312 + adapter 1.3.0 + preCICE 3.1.1.
So we should already have the fix you mentioned. The reason we are running two different versions of preCICE is simply that I haven’t updated the OpenFOAM docker to include the new version. Do you think this could be an issue?

EDIT: I also just remembered that I build preCICE 3.1.2 in the MATLAB Docker from source and used the pre-build binary of preCICE 3.1.1 for the OpenFOAM Docker.

4

Mixing preCICE versions is a very unusual thing to do. We don’t guarantee any compatibility between versions.
I would advise you to first get the precice version identical and then see how this impacts the behaviour.

What Compiler and flags do you use for building from source? Is there a reason you don’t use the provided Debian packages?

5

Hi,
Yes, it really happened by accident. I was having issues getting the MATLAB bindings to work, likely linked to this issue: OpenMPI Issues MATLAB bindings
I made it work by building preCICE from source, like suggested in the issue. So when I downloaded the preCICE source, I accidentally downloaded v3.1.2. For the OpenFOAM docker I stuck to the prebuild package. I have now updated the OpenFOAM docker to 3.1.2 and will report back if this fixes my issues. Otherwise I will build a new Docker image with preCICE build from source for both of them.

2 Likes
6

So, we now tested using the two dockers running preCICE 3.1.2 and we still get the same error. I will also now test using preCICE build from source on both of them.
Something I don’t understand is, why does preCICE only crash in the last time step. If its a floating point error, should’t this happen every coupling time step at which the error accumulation is to large? It happen if we run a simulation for 200s of simulated time but also at 500s.

One thing we are also unsure about, is the order of calling preCICE. In the OpenFOAM adapter its:
write()
advance(dt)
read()

However, in the MATLAB bindings solverdummy its:
read()
write()
advance()

Doesn’t this introduce a shift in timing?

7

I don’t know, but this is definitely a lead. Let’s clarify the order first.

In the OpenFOAM adapter, the order is weird because of the points where we can inject code to OpenFOAM using the function objects interface (see OpenFOAM-preCICE: Coupling OpenFOAM with External Solvers for Multi-Physics Simulations | OpenFOAM® Journal and my Master’s thesis). In short, the adapter is always called in the beginning of the next solver time step, not at the end of the current time step.

The order we typically use is read-solve-write-advance in the time loop. This also pairs well with the initialization before the loop:

8

Ok, understood. So the order of read-solve-write-advance is just shifted over the timestep boundary.

Is there some thing we can test on our side to see whats going wrong on the last time step?

9

Could you add the exact logs of the solver and preCICE, showing the order of everything and the number of iterations, time, etc?