# Distributed parallelilzation and corresponding mapping **URL:** \ **Category:** Using preCICE\ **Tags:** data-mapping, parallel\ **Created:** [June 23, 2021, 9:31am UTC](https://precice.discourse.group/t/distributed-parallelilzation-and-corresponding-mapping/641 "2021-06-23T09:31:56Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![MaxFirmbach](https://avatars.discourse-cdn.com/v4/letter/m/74df32/32.png) [@MaxFirmbach](https://precice.discourse.group/u/MaxFirmbach)\ **Post date:** [June 23, 2021, 9:31am UTC](https://precice.discourse.group/t/distributed-parallelilzation-and-corresponding-mapping/641/1 "2021-06-23T09:31:56Z")
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](https://precice.discourse.group/uploads/short-url/eOSd2gHVoZwTIjaLCiPlf1VI8Xu.xml) (2.7 KB) ---
**Author:** ![uekerman](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/uekerman/32/2199_2.png) [@uekerman](https://precice.discourse.group/u/uekerman)\ **Post date:** [June 23, 2021, 12:39pm UTC](https://precice.discourse.group/t/distributed-parallelilzation-and-corresponding-mapping/641/2 "2021-06-23T12:39:35Z")
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](https://precice.org/couple-your-code-distributed-meshes.html) ---
**Author:** ![MaxFirmbach](https://avatars.discourse-cdn.com/v4/letter/m/74df32/32.png) [@MaxFirmbach](https://precice.discourse.group/u/MaxFirmbach)\ **Post date:** [June 25, 2021, 9:49am UTC](https://precice.discourse.group/t/distributed-parallelilzation-and-corresponding-mapping/641/3 "2021-06-25T09:49:33Z")
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: ![Mapping](https://global.discourse-cdn.com/free1/uploads/precice/original/1X/c5df8d7b686d741d25db6809ba4891b692bb7f4b.png) 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 … ---
**Author:** ![uekerman](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/uekerman/32/2199_2.png) [@uekerman](https://precice.discourse.group/u/uekerman)\ **Post date:** [June 27, 2021, 2:58pm UTC](https://precice.discourse.group/t/distributed-parallelilzation-and-corresponding-mapping/641/4 "2021-06-27T14:58:35Z")
> [@MaxFirmbach](#): > > Ok, this makes sense and I see the same effect in my force vector. Is this behavior also the same for an rbf-interpolation ? 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. > [@MaxFirmbach](#): > > 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 … 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?