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

**URL:** <https://precice.discourse.group/t/dealing-with-steady-state-and-time-dependent-couplings-in-precice-a-case-study-in-fluid-structure-interaction/2526>\
**Category:** Uncategorized\
**Tags:** adapters, data-mapping, dealii\
**Created:** [June 3, 2025, 4:30pm UTC](https://precice.discourse.group/t/dealing-with-steady-state-and-time-dependent-couplings-in-precice-a-case-study-in-fluid-structure-interaction/2526 "2025-06-03T16:30:53Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![lucacattarossi](https://avatars.discourse-cdn.com/v4/letter/l/ea666f/32.png) [@lucacattarossi](https://precice.discourse.group/u/lucacattarossi)\
**Post date:** [June 3, 2025, 4:30pm UTC](https://precice.discourse.group/t/dealing-with-steady-state-and-time-dependent-couplings-in-precice-a-case-study-in-fluid-structure-interaction/2526/1 "2025-06-03T16:30:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![fsimonis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/fsimonis/32/6_2.png) [@fsimonis](https://precice.discourse.group/u/fsimonis)\
**Post date:** [June 6, 2025, 9:01am UTC](https://precice.discourse.group/t/dealing-with-steady-state-and-time-dependent-couplings-in-precice-a-case-study-in-fluid-structure-interaction/2526/2 "2025-06-06T09:01:46Z")

</div>

> [@lucacattarossi](#):
>
> Interestingly, when I switch to `rbf` mapping, the warning disappears

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.

> [@lucacattarossi](#):
>
> 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.

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

> <https://github.com/precice/precice/issues/998>
>
> \*\*Please describe the problem you are trying to solve.\*\*
> 
> Having duplicate ver…tices in a mesh is a common issue for users of the RBF mappings.
> Currently, preCICE does not have very descriptive error messages as there are many things that could go wrong with RBF.
> 
> \*\*Describe the solution you propose.\*\*
> 
> We could use the index trees to efficiently check for duplications and stop preCICE with an error message listing the repeated coordinates.
> 
> A possible configuration could look like this:
> \`\`\`xml
> \<mapping:rbf-thin-plate-splines direction="read" from="MyMesh2" to="MyMesh1" constraint="consistent" check-duplicates="1"/\>
> \`\`\`
> 
> This could be the resulting error message:
> \`\`\`
> ERROR: Mesh "MyMesh1" uses RBF but has vertices with duplicate coordinates, which is not allowed. Please use a different mapping or remove duplicates at these coordinates: \[(0,0,0), (1,2,3)\]
> \`\`\`
> 
> \*\*Open questions:\*\*
> \* Should this be turned on by default?
> \* Should this be configured in the RBF mapping tag or globally?
> \* Does it suffice to check the local partitions in case of a parallel solver?
> \* Do we need to check both input and output mesh?
> 
> \*\*Describe alternatives you've considered\*\*
> 
> Provide scripts to check input meshes. This however does not help if the adapter creates duplicate vertices.
> 
> \*\*Additional context\*\*
> 
> \_nothing yet\_

---

<div class="post-metadata">

**Author:** ![lucacattarossi](https://avatars.discourse-cdn.com/v4/letter/l/ea666f/32.png) [@lucacattarossi](https://precice.discourse.group/u/lucacattarossi)\
**Post date:** [June 6, 2025, 9:09am UTC](https://precice.discourse.group/t/dealing-with-steady-state-and-time-dependent-couplings-in-precice-a-case-study-in-fluid-structure-interaction/2526/3 "2025-06-06T09:09:02Z")

</div>

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?