Non-existing mapping is not detected

[carme-hp]

Describe your setup

Operating system (e.g. Linux distribution and version): Ubuntu 22.04
preCICE Version: 3.1.0

Describe the problem
After the creation of a compositional scheme (before finishing the first coupling timestep) consisting of a serial-explicit + parallel-implicit scheme, we face the following error in the participant which is present in both schemes:

The error was solved by adding a missing mapping to the crashing participant (see commit ).

Expected behaviour
preCICE should tell, that the mapping doesn't exist. Debugging xml files in compositional coupling schemes is challenging.

Additional context

FYI @davidscn

[davidscn]

Given the multitude of application scenarios, we cannot detect a 'missing mapping', as there are some scenarios, which don't require a mapping in the first place. What we could check, however, is that we try to read data (e.g. Displacement) on a mesh (MuscleMeshBottom), where we never receive this data (neither via a mapping nor via an exchange).

[fsimonis]

A naive check could verify that every mesh is either mapped or received by another participant. This would also play nicely with direct-mesh-access.

@uekerman could a participant write data to a mesh solely for the sake of providing a custom convergence measure or primary data for acceleration?

As @davidscn mentioned, this is also vaguely related to #1865, which would allow us to check this kind of issue on a data-level.

[fsimonis]

@carme-hp isn't this easy to spot using the config-visualizer?

[carme-hp]

I mean i didn't think that it would be a mapping thing, so i didn't see it. But yes, you can see it with the config-visualizer:

[uekerman]

@uekerman could a participant write data to a mesh solely for the sake of providing a custom convergence measure or primary data for acceleration?

Yes, or for a watchpoint, for exporting, ...

[fsimonis]

Meaning, that we cannot properly check this.

Providing for the sake of exporting sounds like it should be painless to turn the exporter off.

Receiving for the sole sake of using in a convergence measure or acceleration should also be easy to turn off.

Emitting warnings yes, but raising errors no. Correct?