# Coupling crash readData(...) only long simulations **URL:** \ **Category:** Using preCICE\ **Tags:** openfoam, matlab\ **Created:** [August 23, 2024, 8:36am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083 "2024-08-23T08:36:54Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![openFoe](https://avatars.discourse-cdn.com/v4/letter/o/a9a28c/32.png) [@openFoe](https://precice.discourse.group/u/openFoe)\ **Post date:** [August 23, 2024, 8:36am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/1 "2024-08-23T08:36:54Z")
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 ---
**Author:** ![fsimonis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/fsimonis/32/6_2.png) [@fsimonis](https://precice.discourse.group/u/fsimonis)\ **Post date:** [August 24, 2024, 7:26am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/2 "2024-08-24T07:26:18Z")
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](https://github.com/precice/precice/releases/tag/v3.1.0). Best regards Frédéric ---
**Author:** ![openFoe](https://avatars.discourse-cdn.com/v4/letter/o/a9a28c/32.png) [@openFoe](https://precice.discourse.group/u/openFoe)\ **Post date:** [August 26, 2024, 7:01am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/3 "2024-08-26T07:01:35Z")
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. ---
**Author:** ![fsimonis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/fsimonis/32/6_2.png) [@fsimonis](https://precice.discourse.group/u/fsimonis)\ **Post date:** [August 31, 2024, 7:22am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/4 "2024-08-31T07:22:45Z")
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? ---
**Author:** ![openFoe](https://avatars.discourse-cdn.com/v4/letter/o/a9a28c/32.png) [@openFoe](https://precice.discourse.group/u/openFoe)\ **Post date:** [September 2, 2024, 8:41am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/5 "2024-09-02T08:41:31Z")
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](https://github.com/precice/matlab-bindings/issues/19) 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. ---
**Author:** ![openFoe](https://avatars.discourse-cdn.com/v4/letter/o/a9a28c/32.png) [@openFoe](https://precice.discourse.group/u/openFoe)\ **Post date:** [September 16, 2024, 8:22am UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/6 "2024-09-16T08:22:56Z")
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? ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [September 16, 2024, 4:38pm UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/7 "2024-09-16T16:38:38Z")
> [@openFoe](#): > > Something I don’t understand is, why does preCICE only crash in the last time step. I don’t know, but this is definitely a lead. Let’s clarify the order first. > [@openFoe](#): > > One thing we are also unsure about, is the order of calling preCICE. In the OpenFOAM adapter its: 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](https://journal.openfoam.com/index.php/ofj/article/view/88) 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: > **[Step 3 – Mesh and data access](https://precice.org/couple-your-code-mesh-and-data-access.html)** > > In this step, we see how to define coupling meshes and access coupling data. > **[Step 7 - Data initialization](https://precice.org/couple-your-code-initializing-coupling-data.html)** > > As default values, preCICE assumes that all coupling variables are zero initially. For fluid-structure interaction, for example, this means that the structure is in its reference state. Sometimes, you want to change this behavior – for instance, you... ---
**Author:** ![openFoe](https://avatars.discourse-cdn.com/v4/letter/o/a9a28c/32.png) [@openFoe](https://precice.discourse.group/u/openFoe)\ **Post date:** [September 17, 2024, 12:23pm UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/8 "2024-09-17T12:23:49Z")
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? ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [September 23, 2024, 12:43pm UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/9 "2024-09-23T12:43:07Z")
Could you add the exact logs of the solver and preCICE, showing the order of everything and the number of iterations, time, etc? ---
**Author:** ![fsimonis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/fsimonis/32/6_2.png) [@fsimonis](https://precice.discourse.group/u/fsimonis)\ **Post date:** [August 12, 2025, 3:47pm UTC](https://precice.discourse.group/t/coupling-crash-readdata-only-long-simulations/2083/10 "2025-08-12T15:47:06Z")
@openFoe If you are using ``, then you may be running into this bug: > > > \## Main changes of this PR > > This PR fixes severe rounding error when computing t…he passed time to send to the second participant using \`\\`. > > \## Motivation and additional information > > See this \[Discourse post\](https://precice.discourse.group/t/issue-with-variable-time-window-size-in-serial-explicit-coupling-readdata-cannot-sample-data-outside-of-current-time-window/2592) > > This was not yet ported to the new time accumulators. > > \## Author's checklist > > \* \[y\] I used the \[\`pre-commit\` hook\](https://precice.org/dev-docs-dev-tooling.html#setting-up-pre-commit) to prevent dirty commits and used \`pre-commit run --all\` to format old commits. > \* \[\] I added a changelog file with \`make changelog\` if there are user-observable changes since the last release. > \* \[\] I added a test to cover the proposed changes in our test suite. > \* \[\] For breaking changes: I documented the changes in the appropriate \[porting guide\](https://precice.org/couple-your-code-porting-overview.html). > \* \[x\] I stuck to C++17 features. > \* \[x\] I stuck to CMake version 3.22.1. > \* \[\] I squashed / am about to squash all commits that should be seen as one. > \* \[\] I ran the systemtests by adding the label \`trigger-system-tests\` (may be skipped if minor change)