# How to set up the dynamic mesh for a piston moving through a tube of variable diameter?

The tutorial case incompressible/pimpleDyMFoam/movingCone describes a cone moving through a "tube" (if you change the far-field patch into a wall) of constant diameter. This is the most related tutorial case I can think of, since what I want to simulate is the same geometry but with a jump in diameter. If any of the following turns this into a XY problem please interrupt me.

In the tutorial case, instead of moving only the cone, which would distort the surrounding mesh too much, the outer patch (representing the far-field, which I'd replace by a type wall) is split into a part moving along with the cone (farFieldMoving) and two other parts (farField) with a slip movement (see 0/pointMotionUx). This results in three dynamic tube segments, where the middle one contains the cone, is moving but fixed in dimensions, while the outer segments expand/compress correspondingly. This method can however not be directly applied to the modification I would like to put on the geometry, namely a jump in diameter along the cone's motion axis - the wall segment moving along with the cone is no longer a constant. (Please correct me if I'm wrong there)

These are the Ansätze (that's the German plural of Ansatz, please edit in a better wording...) I could think of, each of which lacks some knowledge from my part:

1. Just move a cone-shaped hole through the fixed tube mesh
2. Move the cone inside a smaller virtual tube and connect that tube's outer boundary to the physical tube via AMIs
3. Move that entire virtual tube (make it longer than the physical one) and treat the non-overlapping AMI parts somehow
4. Simulate the cone-fixed inertial system where the wall dynamically expands/contracts

Some more details:

1. The ideal solution would probably be a fixed tube mesh wherein a cone-shaped hole is moving and distorting only the cells on the cone boundary. I suspect this can be achieved with topoChangerFvMesh or more precisely movingConeTopoFvMesh, but I can't find any tutorial using it nor any documentation. I am also not familiar enough (yet) with the OpenFOAM code to understand the usage by simply looking at the source code. So, are there any resources you could point me to?

2. The other approach I consider is using the Arbitrary Mesh Interface (AMI): Put the cone in a smaller tube inside the physical one and connect the virtual interfaces via cyclicAMI, assuming these AMIs do not actually have to be cyclic. Unfortunately, the connection using the neighbourPatch keyword requires both partner boundaries to be equal in area. This means I cannot simply let the AMI touch the moving hole since there is no face to match. If I add a small cell layer, the AMI can match, but I have the problem of distorting cells again. So I think I could use the movingCone-tutorial approach of moving part of the inner AMI parallel to the cone-hole. But since I can only connect two equally sized faces via the neighbourPatch keyword, I cannot split the inner AMI into two slipping parts embracing a moving part. Can this be achieved some other way? So, either how can AMIs that are split up in multiple boundaries be coupled, or how can one AMI be split into multiple sub-boundaries that have different boundary conditions (in pointMotionUx)?

3. Moving the virtual tube means only part of the inner AMI actually matches the outer one, the remainder would have to be of some other type. Again the problem is that the AMIs have to be matching faces.

4. I didn't investigate much on changing the inertial system. I suspect this would have the advantage that "only" the outer walls have to move towards/away from the tube center while the cells would only slightly deform, the disadvantage would be the change of reference frame, where walls might require special treatment (as is hinted at here, although that is for the Bernoulli equation).

I hope some of you have ideas how to either complete these attempts to a full solution or suggest another way (which may turn out to be more simple...).

• (also asked at cfd-online.com) Jul 4, 2012 at 10:57

## 1 Answer

If you consider introducing a topological change to the mesh, there is a tutorial explaining exactly the problem that you are facing. Here you can find the background of the case: Modification of a movingConeTopoFvMesh. Because of cell layer removal, I think that it should be possible to have a cylinder mesh with variable radius without a problem: removed cell layer is created using the cone patch that is translated to deflate, and destroy, the cells.

A tutorial case is also present in the 1.6-ext version of OpenFOAM in the folder incompressible/icoDyMFoam/movingConeTopo/.

Example of new "cylinder" width: In the tutorial case, in the blockMeshDict file, add another block above block 4, with the appropriate density to match the block 4, and be sure to change the patches accordingly (the top patch of the 4th block in the direction of the Y axis needs to be deleted, because its faces are now internal).

• Thanks, I think what that modifications implements can now directly be achieved using an AMI in 2.1. At the moment my solution consists of using a one cell thick layer around the cone embedded in the virtual cylinder I mentioned. It would of course be more convenient if that layer could be removed... Jul 9, 2012 at 7:36
• Okay, but is it not possible to just use the topological mesh changes? Do you absolutely need AMI? I have nothing against sliding interfaces, I'm just interested in the problem.. :) If you use mesh motion, you will experience cell deformation, on the other hand, the topological changes will mess with the aspect ratio of the mesh as well... Jul 9, 2012 at 8:57
• I'm afraid some deformation is always involved, although I'd be interested in the least obtrusive version. Which I suspect a moving hole that only modifies the boundary-touching cells might be... Jul 9, 2012 at 11:23
• Yep, this sounds right. The question is if the distorted/deleted cells by the patch of the cone if the topology is changed introduce more errors, than conservative mapping of fields across the AMI patch. Jul 9, 2012 at 11:42