# Moving mesh support in volume-coupling **URL:** \ **Category:** Using preCICE\ **Tags:** openfoam\ **Created:** [April 8, 2024, 3:50am UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871 "2024-04-08T03:50:34Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Ya\_Squall](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/ya_squall/32/2265_2.png) [@Ya\_Squall](https://precice.discourse.group/u/Ya_Squall)\ **Post date:** [April 8, 2024, 3:50am UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/1 "2024-04-08T03:50:34Z")
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, ---
**Author:** ![Ya\_Squall](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/ya_squall/32/2265_2.png) [@Ya\_Squall](https://precice.discourse.group/u/Ya_Squall)\ **Post date:** [April 18, 2024, 3:19am UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/2 "2024-04-18T03:19:19Z")
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! ---
**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:** [April 18, 2024, 8:53am UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/3 "2024-04-18T08:53:51Z")
The search is your friend: > [@Can preCICE be used with moving meshes?](https://precice.discourse.group/t/can-precice-be-used-with-moving-meshes/53): > > What happens when the interface is moving? A working alternative is [to directly access the mesh](https://precice.org/couple-your-code-direct-access.html) of the static solver and perform a data mapping to the moving domain in the adapter of the moving one. ---
**Author:** ![Ya\_Squall](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/ya_squall/32/2265_2.png) [@Ya\_Squall](https://precice.discourse.group/u/Ya_Squall)\ **Post date:** [April 21, 2024, 3:28am UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/4 "2024-04-21T03:28:55Z")
Thanks. What if the input mesh itself is deforming but without topology change? In my scenario, both input and output meshes are dynamic ones. ---
**Author:** ![Ya\_Squall](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/ya_squall/32/2265_2.png) [@Ya\_Squall](https://precice.discourse.group/u/Ya_Squall)\ **Post date:** [April 22, 2024, 3:52am UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/5 "2024-04-22T03:52:36Z")
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. ---
**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:** [April 22, 2024, 4:32pm UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/6 "2024-04-22T16:32:04Z")
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. ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [May 6, 2024, 2:20pm UTC](https://precice.discourse.group/t/moving-mesh-support-in-volume-coupling/1871/7 "2024-05-06T14:20:13Z")
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.