Crash in Fortran binding precicef_read_data when coupling with preCICE

[cysanghavi]

I am using the Fortran bindings to couple a Fortran code (MESHFREE) with itself via preCICE.

To simplify the problem, I’m currently testing with a very small setup:

• 1 MPI rank for each participant (“Air” and “Water”)

• “Water” should send a vector field (velocity, 3 components) to “Air”

• “Air” should send a scalar field (pressure) back to “Water”

The relevant parts of my setup:

• preCICE version: 3.2.0 (I will upgrade to the newer version ASAP)

• Platform / compiler: ifortx, RHEL-9.7

• preCICE configuration: see attached precice-config.xml

  precice-config.xml (3.3 KB)

• Fortran interface: see attached Crash_routine.txt

  Crash_routine.txt (2.3 KB)

• Air and Water Participant log files:

output_Air.txt (1.1 MB)

output_Water.txt (465.7 KB) (Crashes here)

Coupling logic (high-level):

• I only start coupling after the first two time steps (since the MESHFREE point cloud size may change in the first steps, and I wanted to avoid using advanced mappings initially).

Observed behavior:

• The Air participant runs through its time window and appears to receive data from Water correctly.

• The Water participant crashes as soon as it tries to read data from Air.

• The crash seems to originate exactly at the call to the C interface:

  call precicef_read_data(precice_meshName, precice_readDataName, PC%Y_index(2), &
  precice_vertexIDs, dt, precice_readData, &
  len(precice_meshName), len(precice_readDataName))

• If I comment out this line and instead do: precice_readData(:) = 0.0 then the simulation runs without crashing.

• I also tried to pass only one velocity comment, i.e. only a single dimensional field from each side and I could still observe the same error.

Details on data types and array sizes:

• _real4fpm_ is 8‑byte (double precision), _integer4fpm_ is 4‑byte.

• The interface declarations in my Fortran module match the types from precice.f90 (real8 for dt and values, integer4 for sizes and IDs).

• precice_readData is allocated with the expected size:

  • For Water (reading pressure) → size PC%Y_index(2) (scalar per vertex).

  • For Air (reading velocity) → size PC%Y_index(2) * 3 (vector per vertex).

• I verified that precice_dimensions = 3 from precicef_get_mesh_dimensions.

My question :

1. Are the dimensions of the vector data in the XML <data:...> definition used to define the size of the readData values internally? Or does this work exactly to the size I allocated in my coupling code?
2. Am I missing something obvious ? I am relatively new to preCICE. Any confirmation that this is indeed just a misconfiguration on my side (data dimension mismatch), or that I am missing something else in the Fortran binding usage, would be very helpful.

Thanks a lot for any suggestion or help in advance, I really appreciate the community.

[Ray_Scarr]

Your precice-config.xml declares both exchanged quantities as data:vector. Not knowing your code, I would expect pressure to be data:scalar and this would explain your crash if one participant expects to read three times as much data as is actually being received.

[cysanghavi]

Thanks a lot, this was actually the issue and solves the problem. With “scalar” I assumed really only one singular value for the complete data exchange. Its rather a “scalar” value per node / point.

I am still a little confused how does precice know the dimensions of my field simply by description in the config. file. I could in theory transfer a stress field where the dimensions could be different. I was under the impression this is decided by the allocation size of this data structure (in my case AirToWater).

[Ray_Scarr]

If you have a data:vector quantity, the number of components in each vector is equal to the number of spatial dimensions of the mesh across which that quantity is exchanged (see the XML reference documentation here). If you wanted to exchange a 3x3 stress tensor at each coupling point, you could use three separate data:vector quantities or nine separate data:scalar quantities.

[cysanghavi]

Perfect, thanks a lot.