I am extending a working adapter for an in-house fluid solver to support reading displacements for FSI, aiming toward the perpendicular flap tutorial. Since that tutorial exists preCICE must be able to handle this sort of thing, despite this FAQ answer suggesting otherwise and the moving-mesh section of the adapter guide being blank. For the foreseeable future I only need the mesh to deform, so connectivity won’t change but the locations of mesh nodes will. The way I envision this working is:
Solid solver has its coupling mesh.
Fluid solver has its coupling mesh, possibly with vertices at different locations than the solid mesh.
Solid solver computes displacements, applies them to its nodes, then writes displacement values to preCICE and sets its new node locations.
Fluid solver reads (interpolated) displacements, applies them to its mesh, converges its solution on the newly deformed mesh, then writes forces to preCICE and sets its new node locations.
So at each window my fluid solver would just need to tell preCICE its new node locations, in addition to the displacements which are written just as any other vector quantity would be. Am I missing any other considerations?
By “moving meshes”, we mean that the topology of the interface changes. This is something once typically encounters in sliding contacts or rotating bodies. The typical FSI examples, such as the perpendicular flap, don’t have moving meshes in that sense. They use the ALE approach: Every solid mesh point remains mapped to the same fluid mesh points during the whole simulation. Displacement is only another field that is exchanged and applied in the model and visualization.
What you describe sounds like the typical FSI scenarios preCICE is already being used for and everything should work.
@Makis Thank you, that notion of moving mesh makes sense now. Just to make sure I understand, because the mappings between meshes do not change there is never a situation where a participant should call setMeshVertices more than once in a simulation?