CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Programming & Development (
-   -   Nested Sliding Interfaces (

lordvon August 14, 2013 23:46

Nested Sliding Interfaces
Hello All,
I want to simulate sliding interfaces inside of other sliding interfaces. The rotation centers would not be coaxial, and therefore axes of rotation will be themselves rotating with the grid that contains them, that is also rotating.
AFAIK OpenFOAM currently is hard-coded to handle one rotating region, though I have seen a post around here of some users making modifications for multiple rotating zones, but of course these are not nestable.
Could someone point me in the right direction for doing this in OpenFOAM?

kalle August 15, 2013 02:26


I am not sure I fully understand your domain, but I'd say that you should write your own mesh motion class. If your sliding interfaces all the time are fully overlapping, I'd recommend you to use GGI or AMI, as that is easy to parallelize. If they are not fully overlapping, you do need sliding interfaces. They are somewhat parallelizable in 1.6-ext, if you make sure each sliding interface pair stays fully on individual processors (i.e. they do not interact with any processor boundaries).

For writing mesh motion classes in GGI/AMI look at the mixerGgiFvMesh class in 1.6-ext. For sliding interface, look at mixerFvMesh. If you can mathematically describe each vertex's motion, it should be fairly straight forward.


lordvon August 15, 2013 10:40

Thank you very much for your reply, kalle.

A few clarifications:

1- What is meant by full overlapping?

2- About what I am trying to do, please take a look at this video:

At 6:15:

In order to simulate that motion in OpenFOAM, an AMI can be placed around the vorticity meter, while a second much larger AMI needs to be placed to facilitate the rotation that allows the vorticity meter to move in its circular path around the tank. Please let me know if its still not clear what I want to do.

lordvon August 15, 2013 10:56

1 Attachment(s)
an illustration (here they have same direction rotation vector, but in the video I gave the rotation vectors are antiparallel)

kalle August 16, 2013 01:24

I see... Fully overlapping means that the two patches completely cover each other. This seems to be the case for your setup, so go for AMI or GGI. Just look how the mixerGgi mesh class does the motion, and write your own class!


lordvon August 16, 2013 09:59

I guess I will start with dynamicFvMesh, since this does not have the limitation of one rotating zone hard-coded, as indicated here:


kalle August 16, 2013 14:38

The dynamicFvMesh class is an abstract class - all the non-topological mesh motion classes derives from it. It contains hence no functionality for actual mesh motion, but it specifies all the methods the deriving classes has to implement.

Since one of you rotating part is rotating with the other one, I am pretty sure that none of the standard classes will do, but most of what you need is present in the mixerGgi class. A similar class in 2.2 is solidBodyMotionFvMesh, but I have never looked at it. That class is used by the propeller AMI tutorial.


lordvon August 27, 2013 22:14

Do you think I will have to modify any part of AMI source? Hopefully I will only have to write source for the rigid body motions.

kalle August 28, 2013 01:09

I have never used AMI, but I would be very surprised if you had to touch any of the AMI related code!

lordvon August 28, 2013 14:12

It seems like simply modifying one of the solidBodyMotionFunctions may suffice!

kalle August 28, 2013 14:32

Yes, that might do the trick.

lordvon August 29, 2013 01:52

In the case I described, looking at the nested (small) AMI, I will have to apply a rotation due to the housing (large) AMI and then another rotation due to the prescribed rotation rate for the nested AMI.

To do this in terms of septernions, would I just multiply all of these processes together? I understand that in the original axisRotationMotion definition, the rotation at a specified CofG (rotation center) is performed by:


Where R is the rotation quaternion about the origin (0,0,0) for the specified rotation vector. Would my intention be realized by the following?


Where R2 and CofG2 are the rotation quaternion and center of rotation, respectively, local to the small AMI.

kalle August 29, 2013 02:08

I have never used those rotation/translation classes, so I can't tell... looks like the system's motion can be described fairly straightforward though.

lordvon September 3, 2013 14:31

Turns out the septernion/quaternion manipulation I described earlier is correct. I finally managed to get it working exactly the way I wanted to with ease.

Thanks for the helpful hints!

I would post the code, but it is so tailored specifically to my application that I would doubt it would be helpful to others more than the general procedure.

All times are GMT -4. The time now is 07:52.