Hello preCICE developers & community,
I have a question regarding distributed parallelism and data-mappings.
Is it valid to use a distributed mesh and call the setMeshVertices() method for
each rank ? In my case this would result in a certain amount of coupling vertices
on each rank, where some of them are copies (so they exist on several ranks
due to overlap and ghost layers).
Afterwards, I use a nearest-neighbor mapping and observed that most entries of the force vector I read
from a sequential OpenFoam run are just zero (normally there should be more entries in there, which are nonzero, which I checked for a sequential run on the structure side).
Technically, this should all just work out of the box, but I’m not sure why it behaves like this …
I also attached the precice-config file, maybe something there has to be adjusted.
Thank’s for the help!
Max
precice-config.xml (2.7 KB)
Distributed meshes are tricky. If a vertex is duplicated, a conservative NN mapping to this mesh only hits one of both vertices.
We collected detailed information on this topic here: Dealing with distributed meshes | preCICE - The Coupling Library
1 Like
Ok, this makes sense and I see the same effect in my force vector. Is this behavior also the same for an rbf-interpolation ?
So reading the topic about distributed meshes, I’m actually not quite sure, what happens the other way round (consistent reading Mesh 1 ← Mesh 2). I made a small sketch:
Is one of the both vertices also omitted in this case and only the value of one mapped to Mesh 1 ? It is still bit unclear for me …
In principle yes. If you have a conservative mapping to a mesh that has duplicated vertices, the sum of the force contributions on these vertices give the correct sum. For NN, you get 0 force on the one vertex and the full force on the other vertex. For an RBF mapping the distribution is smoother, but you still only get parts of the force on each vertex.
The case you describe is probably a write-consistent mapping, not a read-consistent mapping.
In this case, you have exactly the problem you describe, which value to choose? This is the reason why this case (and similarly read-conservative) is currently not supported in preCICE when you run the participant in parallel.
Maybe interesting to know: In his PhD, @DavidSCN is working towards a more general solution or such problems. Maybe averaging could be a way to go?
