Dealing with Steady-State and Time-Dependent Couplings in preCICE: A Case Study in Fluid-Structure Interaction

, ,
1

Hello everyone,

I’d like to share an issue I recently encountered while working on a fluid-structure interaction (FSI) simulation using preCICE. The problem appears when I start running the fluid participant in parallel.

This is part of the log I get:

---[precice]  Setting up primary communication to coupling partner/s
---[precice]  Primary ranks are connected
---[precice]  Setting up preliminary secondary communication to coupling partner/s
---[precice]  Prepare partition for mesh FluidMesh
---[precice]  Gather mesh FluidMesh
---[precice]  Send global mesh FluidMesh
---[precice]  Receive global mesh StructureMesh
---[precice]  Broadcast mesh StructureMesh
---[precice]  Filter mesh StructureMesh by bounding box on secondary ranks
---[precice]  Mapping distance min:2.77556e-17 max:0.0197826 avg: 0.00954335 var: 3.27548e-05 cnt: 1890
---[precice] WARNING:  16082 of 17626 vertices of mesh StructureMesh have been filtered out since they have no influence on the mapping.
---[precice]  Filter mesh StructureMesh by mappings
---[precice]  Feedback distribution for mesh StructureMesh
---[precice]  Setting up secondary communication to coupling partner/s
---[precice]  Secondary ranks are connected
---[precice]  Computing "nearest-neighbor" mapping from mesh "StructureMesh" to mesh "FluidMesh" in "read" direction.
---[precice]  Mapping distance min:2.77556e-17 max:0.0197826 avg: 0.00954335 var: 3.27548e-05 cnt: 1890
---[precice]  Mapping "Displacements" for t=0 from "StructureMesh" to "FluidMesh" (skipped zero sample)
---[precice]  iteration: 1 of 100 (min 1), time-window: 1 of 10, time: 0, time-window-size: 0.005, max-time-step-size: 0.005, ongoing: yes, time-window-complete: no, write-initial-data write-iteration-checkpoint

I’m not sure whether this warning could affect the convergence of my simulation — which, in fact, is currently not converging.

At the moment, I’m using a nearest-neighbor mapping strategy, with the following configuration:

participant name="FluidSolver">
      <provide-mesh name="FluidMesh" />
      <receive-mesh name="StructureMesh" geometric-filter="on-secondary-ranks" from="SolidSolver" safety-factor="5."/>
      <read-data  name="Displacements" mesh="FluidMesh"/>
      <write-data  name="Pressure" mesh="FluidMesh"/>
      <mapping:nearest-neighbor direction="read" from="StructureMesh"
                                to="FluidMesh" constraint="consistent"/>
    </participant>

    <participant name="SolidSolver">
      <provide-mesh name="StructureMesh" />
      <receive-mesh name="FluidMesh" geometric-filter="on-secondary-ranks" from="FluidSolver" safety-factor="5."/>
      <write-data name="Displacements" mesh="StructureMesh"/>
      <read-data  name="Pressure" mesh="StructureMesh"/>
      <mapping:nearest-neighbor direction="read" from="FluidMesh"
                                to="StructureMesh" constraint="consistent"/>

Interestingly, when I switch to rbf mapping, the warning disappears — however, I encounter another error due to duplicate points in my FluidMesh. I tried isolating only one of these duplicate geometry points for coupling, but the error persists.

Does anyone have experience with a similar issue? Could this filtering warning with nearest-neighbor be a reason for the lack of convergence?

NB: On the solid side, I’m using the deal.II adapter as the participant.

2

This is expected behaviour as one mesh is significantly finer than the other one. The consistent nearest-neighbour mapping produces a 1-1 mapping to the mesh that contains 1890 vertices. The other larger mesh provides 17626 points, but at most 1890 are needed for the mapping. Hence, the warning:

---[precice] WARNING:  16082 of 17626 vertices of mesh StructureMesh have been filtered out since they have no influence on the mapping.

RBF mappings use vertices in proximity or all vertices in case of a global function. Therefore, no/fewer vertices can be filtered out by preCICE to reduce communication cost. Note that this doesn’t necessarily result in a better mapping. Nearest-neighbour candidates may match exactly.

We are contemplating on adding a check for this situation. Feedback is welcome!

3

First of all, thank you very much for your answer and the clarifications.
Do you think that this warning, related to the different refinement levels of the two meshes and the use of nearest-neighbour mapping, could affect my simulation results in some way?