[lordvon]

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]

Hi,

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.

K

[lordvon]

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:
http://www.youtube.com/watch?v=loCLkcYEWD4

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]

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

[kalle]

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!

K

[lordvon]

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

http://www.cfd-online.com/Forums/ope...-openfoam.html

Thoughts?

[kalle]

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.

K

[lordvon]

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]

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

[lordvon]

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

[kalle]

Yes, that might do the trick.

[lordvon]

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:

septernion(CofG)*R*septernion(-CofG)

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?

septernion(CofG)*R*septernion(-CofG)*septernion(CofG2)*R2*septernion(-CofG2)

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

[kalle]

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]

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.