Adapters for distributed meshes with possible connectivity

Using preCICE
,
1

I am writing an adapter that needs to handle distributed meshes. The coupling roadmap talks about three approaches, two of which do not allow edges to be defined between vertices owned by different ranks. Obviously that only matters if mesh connectivity is required, but it is unclear to me when connectivity is required and what the cost of not having these cross-rank edges would be for a simulation that requires connectivity. Without understanding that, one can’t decide which of the three methods is best for the expected use cases. So I have several related questions:

  1. My reading of the Uekermann dissertation suggests that preCICE requires mesh connectivity if and only if a nearest projection mapping is used. Is that correct?

  2. Why might a user want or need to use nearest projection instead of nearest neighbor?

  3. Suppose a user runs a simulation that requires connectivity and no cross-rank edges are defined. Would the user notice any negative consequences, such as slower convergence or obvious errors in the solution, due to these missing edges?

  4. Does the preCICE ID assigned to a vertex on a given rank have any meaning on different ranks?

  5. If one implements the second method, the adapter has to know whether the mapping is conservative or consistent. I don’t see a way to determine that using the API. Is there one?

Thank you for your help.

2

Hi @Ray_Scarr :wave:

This is pretty much correct. There are some details, like watchpoints or certain actions that also benefit from mesh connectivity, but it’s mostly about the NP mapping.

If the distance between both meshes is much lower than the mesh width, the error of NP is O(h^2) while the error of NN is only O(h). (RBF mapping needs no connectivity and has a O(h^2) error, but is more expensive to compute)

NP falls back to NN if a vertex of the other mesh would be projected to the missing edge. So, you get there a higher local mapping error. There are certainly situation where you can live with this.

No. The ID is unique per rank, but two different vertices on two different ranks can have the same ID.

No, there is none through the API. But the adapter typically knows which data should be written and whether this data needs a consistent mapping (e.g. temperature, velocity, …) or a conservative mapping (e.g. nodal force).

3

@uekerman Thank you, that’s what I needed to know. Your answer raises another point that is unclear to me:

But the adapter typically knows which data should be written and whether this data needs a consistent mapping (e.g. temperature, velocity, …) or a conservative mapping (e.g. nodal force).

It makes perfect sense that the mapping type should depend on the nature of the physical quantity, but in preCICE config files I see mappings defined by meshes. not quantities. For instance, the heat exchanger example has:

<participant name="Solid">
  <use-mesh name="Solid-to-Fluid-Inner" provide="yes" />
  <use-mesh name="Fluid-Inner-to-Solid" from="Fluid-Inner" />
  <write-data mesh="Solid-to-Fluid-Inner" name="Sink-Temperature-Solid" />
  <write-data mesh="Solid-to-Fluid-Inner" name="Heat-Transfer-Coefficient-Solid" />
  <read-data mesh="Solid-to-Fluid-Inner" name="Sink-Temperature-Fluid-Inner" />
  <read-data mesh="Solid-to-Fluid-Inner" name="Heat-Transfer-Coefficient-Fluid-Inner" />
  <mapping:nearest-neighbor
    constraint="consistent"
    direction="read"
    to="Solid-to-Fluid-Inner"
    from="Fluid-Inner-to-Solid" />
...
</participant>

I suppose this works because both the temperature and heat transfer coefficient should use a consistent mapping for physical reasons. But if instead I had two quantities defined at the same locations, one to be mapped consistently and the other conservatively, it seems that preCICE would need two meshes defined from the same point cloud so that the two different mappings can be defined independently. Is that correct?

4

Exactly, completely correct.

5

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.