Related documentation PR: precice/tutorials#550

mmh, seems there is still a problem. @MakisH any quick guess?

mmh, seems there is still a problem. @MakisH any quick guess?

You can click on the Summary and from the bottom of that page download the runs.
Knowing that a specific case fails (in this case, all the FEniCS and Nutils cases), you can look into the stdout.log, stderr.log, and the logs of each participant.

The issue is independent of the system tests: it's the familiar NumPy 2.0 incompatibility.

To fix it, we would need a bugfix release in the tutorials (which I cannot prepare this week).

To fix it, we would need a bugfix release in the tutorials (which I cannot prepare this week).

I switched to develop for the moment such that we can test if everything else works.

Current state:

• Elastic tube 1D (fluid-cpp, solid-python): ✔️
• Flow over heated plate (fluid-openfoam, solid-nutils): ✔️
• Flow over heated plate (fluid-openfoam, solid-fenics): ✔️
• Flow over heated plate (fluid-openfoam, solid-openfoam): ✔️
• Perpendicular flap (fluid-openfoam, solid-calculix): ❌ Results regression (!)
• Perpendicular flap (fluid-su2, solid-fenics): ❌ Results regression (!)

Looking into the failing job, trying to understand the regression in the perpendicular flap, which is now also raised in precice/tutorials#573.

The reference results used have been created with (download the runs, look into the SU2-FEniCS reference_results.metadata:

Watchpoint for OpenFOAM-CalculiX:

Watchpoint for SU2-FEniCS:

How it should be: https://precice.org/tutorials-perpendicular-flap.html#post-processing

Related commits in the tutorials repository: https://github.com/precice/tutorials/commits/develop/perpendicular-flap

Now that precice/tutorials#573 is fixed, one test is still failing (Perpendicular flap (fluid-openfoam, solid-calculix)), which completes but reports deviations above tolerance.

Note that I had to manually trigger the system tests to use the released preCICE v3.1.2, because the current develop has changed the names of the exported files, as discussed in #2053 (comment):

gh workflow run run_testsuite_manual.yml -f suites=release_test -f build_args=PLATFORM:ubuntu_2204,PRECICE_REF:v3.1.2,PYTHON_BINDINGS_REF:b6b9ee5,CALCULIX_VERSION:2.20,CALCULIX_ADAPTER_REF:2a5a73a,FENICS_ADAPTER_REF:3de561d,OPENFOAM_EXECUTABLE:openfoam2406,OPENFOAM_ADAPTER_REF:20b4617,SU2_VERSION:7.5.1,SU2_ADAPTER_REF:64d4aff,TUTORIALS_REF:a10e4a6

I will now investigate which of the components causes the deviation and update this comment. Update:

• It is not the CalculiX adapter: https://github.com/precice/tutorials/actions/runs/11728991737/job/32673639785
• It is not the OpenFOAM adapter: https://github.com/precice/tutorials/actions/runs/11729006409/job/32673685864
• It is not the tutorials: https://github.com/precice/tutorials/actions/runs/11729909772
• Distribution v2404 with OpenFOAM v2406: https://github.com/precice/tutorials/actions/runs/11731050706: all tests fail earlier
• Distribution v2404 with OpenFOAM v2312: https://github.com/precice/tutorials/actions/runs/11731059843: all tests fail earlier
• Same as first run, with OpenFOAM v2312 (and preCICE v3.1.2) works: https://github.com/precice/tutorials/actions/runs/11737731893 So, this one is a difference between OpenFOAM v2312 and v2406 (to investigate). Opened an issue: Different results between OpenFOAM v2312 and v2406 tutorials#582

The reason for the still failing test was the different OpenFOAM version. I downgraded to v2312 and waiting for the follow-up to #2053 (comment)

Now all the Python-related system tests fail with the same segfault, but I cannot reproduce this locally. I suspect this has something to do with the layer caching.

Full output of an example: stdout.log
Same file with only the output of solid-python: solid-python.log

I will now clear all the Docker cache and try again. -> did not help

(potentially related issue: precice/tutorials#584)

After debugging a bit with @fsimonis, we found out that the issue currently is in preCICE, since the migration of the exporters to samples (e414c76).

Commit a41d1a2 (one before) does not show the segfault.

The issue is not related to Python, as it also happens in OpenFOAM and in the elastic_tube_1d C++. What the failing cases have in common: nearest-neighbor read-consistent mapping and serial-implicit scheme. One case has data initialization, but the other does not.

Another system tests run that reproduces the issue, with debug and trace information.

• Normal log of Solid: solid-cpp.log
• Debug log: precice-debug.log
• Trace log: precice-trace.log

We are getting closer:

  <participant name="Solid">
    <provide-mesh name="Solid-Nodes-Mesh" />
    <receive-mesh name="Fluid-Nodes-Mesh" from="Fluid" />
    <write-data name="CrossSectionLength" mesh="Solid-Nodes-Mesh" />
    <read-data name="Pressure" mesh="Solid-Nodes-Mesh" />
    <mapping:nearest-neighbor
      direction="read"
      from="Fluid-Nodes-Mesh"
      to="Solid-Nodes-Mesh"
      constraint="consistent" />
      <export:vtk />
  </participant>

We assert here:

For Fluid-Nodes-Mesh and CrossSectionLength. This is data that we neither write/read nor receive. It actually makes no sense to export this data. We could either write zeros or skip the export.