[karkar]

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, don't know 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...).

Regards,
karkar
--
I also posted this at the Computation Science StackExchange: http://scicomp.stackexchange.com/q/2691/1669