Check for duplicate vertices

[fsimonis]

Please describe the problem you are trying to solve.

Having duplicate vertices in a mesh is a common issue for users of the RBF mappings. Currently, preCICE does not have very descriptive error messages as there are many things that could go wrong with RBF.

Describe the solution you propose.

We could use the index trees to efficiently check for duplications and stop preCICE with an error message listing the repeated coordinates.

A possible configuration could look like this:

<mapping:rbf-thin-plate-splines direction="read" from="MyMesh2" to="MyMesh1" constraint="consistent" check-duplicates="1"/>

This could be the resulting error message:

ERROR: Mesh "MyMesh1" uses RBF but has vertices with duplicate coordinates, which is not allowed. Please use a different mapping or remove duplicates at these coordinates: [(0,0,0), (1,2,3)]

Open questions:

• Should this be turned on by default?
• Should this be configured in the RBF mapping tag or globally?
• Does it suffice to check the local partitions in case of a parallel solver?
• Do we need to check both input and output mesh?

Describe alternatives you've considered

Provide scripts to check input meshes. This however does not help if the adapter creates duplicate vertices.

Additional context

nothing yet

[BenjaminRodenberg]

Depending on what you are doing you might even want duplicate vertices. See https://precice.org/couple-your-code-distributed-meshes.html. Therefore I think it's a good idea to make this check configurable.

Does it suffice to check the local partitions in case of a parallel solver?

Yes. Looking at the link above I think this is what we want. We allow having duplicates globally, but not locally.

[davidscn]

This is a very good idea and we should definitely add it. In my opinion it should be a debug feature though.

Should this be turned on by default?

Enabled if NDEBUG is defined.

Should this be configured in the RBF mapping tag or globally?

Enable it independent of the employed mapping since it is still a relevant debug message. (My) adapter development always starts with NN mapping.

Does it suffice to check the local partitions in case of a parallel solver?

I think the check becomes in parallel cases even more relevant. However, I would still see it as a debug feature and disable it in case too many ranks (say >10) are involved.

Do we need to check both input and output mesh?

Input meshes should be enough and we should have internal checks in case things might go wrong during the partitioning.

[uekerman]

• How to work with duplicated vertices and ghost layers is a problem, where we at some point need a decent solution. Potentially within the scope of @DavidSCN 's thesis. For the moment, we are looking for a good check that could serve as a work-around.
• I would not attach this to the mapping. We should check provided meshes. It's not only a problem for RBF, but also for NN and NP. You might then simply get a wrong mapping. And it's not only a problem for mappings, also for exports, actions, acceleration, ...
• I think we should start with checking only the local partitions. This case is clear and easy to check. For global meshes, it sometimes is also simply a feature that we need (see @BenjaminRodenberg 's comment).
• The NDEBUG idea is worth thinking about. We do introduce additional compute complexity only for checking things. I would then also not make it an error message, but simply a DEBUG output. Then, we also don't need a separate configuration.

Provide scripts to check input meshes. This however does not help if the adapter creates duplicate vertices.

In the long run, we want to reload preCICE vtks with ASTE. Then, we could check meshes of users by compiling preCICE in DEBUG mode and using them with ASTE.

[oguzziya]

I am not sure but it might be important for #986 #962 and #963. For connectivity-based mappings, we need to preserve the connectivity elements by defining vertices (and edges) globally multiple times. Otherwise, it will lead to wrong results, even worse broken simulations since scaled-consistent mapping cannot be executed if we do not have any connectivity element on a non-empty partition.

[fsimonis]

So we converge towards:

• Check all meshes independent of mapping.
• Check local meshes only. Global meshes may have to redefine vertices to preserve connectivity information.
• Enable the check by default

Be aware that limiting this check to debug builds means that it will never be "fast". This was my idea of adding a configuration option somewhere so that we could use it in release builds.

We could add further checks similar to the <export:vtk /> tags. Like this:

<participant name="..." />
   <check:vertex-duplication />
</participant>