Duplicated coupling nodes in parallel runs

[davidscn]

When working a bit with samples created from SU2, I realized that SU2/ our adapter implementation currently duplicates interface nodes at rank boundaries. This poses ill-defined mapping problems for preCICE and might lead to (rather) undefined behavior in the solver (although I'm not familiar with the details here in SU2).

We did not notice it so far because the perpendicular-flap tutorial executes all mappings on the fluid side, i.e., the fluid mesh constitutes the output mesh. However, switching the mapping to the solid participant (write->read) and making the Force mapping (physically wrong, only for the experiment here) a consistent mapping, leads to a RBF divergence in parallel, while it works in serial. Looking at the number of vertices in our exports confirms the duplicate definition across multiple ranks.

[uekerman]

This could very well be on purpose, to be able to read the displacement values on all ranks. A common hack.

See also: https://precice.org/couple-your-code-distributed-meshes.html

Not saying that one could not implement a better solution. And presumably it needs documentation ... that conservative mappings from the SU2 mesh and consistent mappings to the SU2 are forbidden.

[davidscn]

Not sure about the hack: using a conservative mapping will mostly be wrong or must be well handled in the adapter: a conservative mapping to the SU2 mesh will lead to conflicting boundary conditions (and will trigger an error in the RBF mapping/singular matrices) on the SU2 side. A consistent mapping from the SU2 mesh will be ill-posed in parallel as well, no real need to forbid them. A consistent mapping so the SU2 mesh might be ok, though.

[kursatyurt]

I don't see any halo node check in the adapter. The halo vertices are also included when setting the mesh see
You need a check as follows before adding that point to mesh see.

[MakisH]

@davidscn @kursatyurt do you think this is still relevant with the rewritten adapter?