Moving mesh support in volume-coupling

Using preCICE
1

Hello there,

I am wondering if it’s possible to further extend the tutorial case “volume-coupled-flow”, such that the “source” domain is moving inside the “fluid” domain. In order to support this change, the cellSet “box1” for the “fluid” mesh needs to be defined in a dynamic approach, instead of predefined at the initial stage. Is there a way to achieve this using the existing Ver-3.1 API? Or this can be worked around by switching to “Kernel methods” based data mapping? Any comments or suggests are urgently expected as I am having an application requiring this capability. Thanks in advance!

Best,

2

Seems that no one is interested in this topic.

In order to allow the “source” domain to move in the “fluid” domain, the cellSet “box1” of fluid-mesh needs to be redefined every time step, using the up-to-date position of the source-mesh. My question is, is there a way in preCICE-v3 to pass this location info from one mesh to another? And after that, it is necessary to repeatly call the API func setMeshVertices(). Will this action be causing trouble to the precice? Please help!

3

The search is your friend:

A working alternative is to directly access the mesh of the static solver and perform a data mapping to the moving domain in the adapter of the moving one.

4

Thanks. What if the input mesh itself is deforming but without topology change? In my scenario, both input and output meshes are dynamic ones.

5

Let it be more specific, I need to exchange (read & write) data between two meshes, one is rigidly moving (i.e. without deforming and re-meshing), another one is performing ALE (i.e. only deforming without re-meshing). Can the direct mesh access be applied? Thanks.

6

I understand “rigidly moving” as “the complete mesh has a dynamic offset”, so it’s freely moving as a unit.

In this case, keep the rigidly moving mesh local and use dynamic mesh access to receive sections of interest from the ALE mesh. Then perform the mapping on the solver with the rigidly moving mesh.

At least, this should give you some starting point.

7

Note that, even with ALE, we don’t support reading displacements over a volume in the OpenFOAM adapter. I guess you could still try defining an internal patch in OpenFOAM, surrounding the volume, and do the FSI coupling over that, while still doing the source coupling over the overlapping volume region. Not sure how much sense that would make, though.