Modelling of a rotary drum
 

Hi everyone! I hope I'm posting my first thread in the correct section :D

I'd like to ask your support to clarify some of the doubts I have about MRF and, in general, how to model rotors. The process I am trying to model is a rotary drum with multiphase fluid inside of it; basically, I am talking about a rotary cylinder that is half filled with water and the rest is air: the motion of the cylinder (along its axialsimetry axis) transmits motion to the fluid inside and I want to study the behaviour of the interface. For this reason, in a first moment I used the interDyMFoam obtaining the expected results but I guess that using a MRF (with interFoam) would reduce the computational cost of the simulation.
I am wondering how this second simulation should be set; I've seen that the MRF requires a cellZone to which the rotation is impressed but, in my case, the rotating drum would just be represented by the thin wall (and thus, in my opinion, only by the cylindrical surface of my mesh). I've tried to use topoSet and setsToZone but what I get is just a faceZone and not a cellZone.

Is there a way to solve this issue avoiding the rotation of the mesh? Should I just set the rotor as the entire cylindric mesh? Any hint or suggestion would be appreciated, I can't wrap my head around it!
Thank you all!

Solved
 

Ok I've found a solution; it may be obvious for most of you but I hope that this will help someone in the future:
interDyMFoam is not needed in this case! Since the problem is very simple, it can be solved by definind the wall (rotor) boundary condition in the file 0/U as:

rotor
{
type rotatingWallVelocity
origin (0 0 0); //coordinates of center of rotation
axis (0 0 1); //direction of the axis of rotation
omega constant 2; // [rad/s]
}

and then I've used interFoam to solve the problem. Using MRF was not necessary

Hello! I also want to simulate a rotary cylinder but I thought that putting an extra interface for the MRF method, would not be right. Do you know how I can simulate the rotation of the mesh? I guess that by using the boundary condition movingWallvelocity, you only get the right results but the mesh is still stable optically, right?