[decanter]

Hello everybody,

it is my first post and I hope that I will write an appropriate one

I am writing my master thesis on simulation of a labor decanter centrifuge, which is used to seperate calcium-carbonate particles from water and I have a critical issue with setting up the case. For your understanding I will first explain the geometry.

The Geometry:

The decanter (pic1) has basically an outer bowl (pic2) and an inner screw (pic4) which are coaxially rotating with slightly different rotational speeds in the same direction. The suspension comes through the feed pipe, which is stationary. It is then distributed through the inlet zone, which rotates with the same speed as the screw. The feed goes through 4 openings into the actuall seperation zone between the outer bowl and screw. (pic3) Here, the seperated particles are transported towards the conus, where they are discarged, and the clarified fluid is transported in the opposite direction to the outlet. I don't simulate the whole length of decanter and only focus on the seperation zone so I cut the geometry before the particle discharge zone. So in reality the conus is longer.

For meshing I am using snappyHexMesh.

Case:

To make it simple I will run the simulation only with water first. I am supposed to use PimpleFoam solver. The actual question is how I can implement the rotation of two surfaces (outer bowl and inner screw). I thought I should use SRF as the whole area between inner and outer cylinders rotates. But in SRF I could only define one particular angular speed. If I use the difference in rotational speeds I neglect the forces which comes from the actual rotation. One idea is to implement these neglected forces in fvOptions. But I am curious, if there is another way to implement two rotational speeds in SRF or in another Reference Frame Method. I think MRF is not suitable as I cannot split the rotational zone due to the screw flights.

I have searched a lot in the internet. There are lots of examples with rotational parts in turbomachinery but the difference that both cylinders are rotating in my case makes it complex and I couldn't find any similar case.

I would really appreciate any tips!
Thank you in advance,
Ayca

[Bloerb]

You could use arbitrary mesh interfaces AMI and rotate the mesh using solidBodyMotion. This makes the meshing process a bit more intricate, but you can define different motion zones moving relative to each other. A steady state is probably not quite possible due to the different rotating velocities.

Or find a reference frame in which one part of your mesh is stationary and define the still rotating part using a boundary condition.

[decanter]

thank you first of all for your answer.

Originally Posted by Bloerb

You could use arbitrary mesh interfaces AMI and rotate the mesh using solidBodyMotion. This makes the meshing process a bit more intricate, but you can define different motion zones moving relative to each other. A steady state is probably not quite possible due to the different rotating velocities.

Where would you implement this AMI? I always thought that the problem is that I can't divide my rotating zone between the cylinders. I mean I have this ring gap between outer bowl and inner screw where the fluid is rotating. There is also no gap between screw flights and outer bowl so they touch eachoter. Do you really suggest that I devide this ring gap into two rotating ring gaps?

[decanter]

Originally Posted by Bloerb

Or find a reference frame in which one part of your mesh is stationary and define the still rotating part using a boundary condition.

I think you mean MRF. I could define the feedPipe as stationary, the rest rotating. But the question is how will you implement two rotating surfaces with different speeds (inner and outer cylinders/conus) in one single rotating zone?

[Bloerb]

Well there is nothing stopping you from using MRF on all of it but the feedPipe. And to include the different rotating speed of the outer wall of the bowl by using a boundary condition like rotatingWallVelocity. I might be missing something though.



For AMI i was thinking about splitting the connection to the feed pipe and the outer walls. And rotate both zones with different speeds. But since there is no gap / the gap is to difficult to resolve this probably isn't the way to go. You could however still use it as a much more computationally expensive version instead of MRF.

[decanter]

Originally Posted by Bloerb

Well there is nothing stopping you from using MRF on all of it but the feedPipe. And to include the different rotating speed of the outer wall of the bowl by using a boundary condition like rotatingWallVelocity. I might be missing something though.

Why I am hesitating about rotatingWallVelocity is that, so far I understood it doesn't apply the centrifugal and coriolis forces in the fluid domain which arise from the rotation. I read on the forum that it doesn't have any component in the normal direction. I guess otherwise we wouldn't need any Reference Frame Method or am I wrong?

[Bloerb]

That's correct. Let's look at a cylinder filled with a fluid. Let's assume we put it on a spinning plate, directly centered. SRF and MRF are identical and only solve in a different reference frame (relative vs inertial reference frame). They both add the rotation as a volumetric source term. Hence they are accounting for the spinning plate without moving the mesh. You could get the same steady state flow by simply applying a rotatingWallVelocity on the surface of the cylinder. The difference is the inertia and hence the start up phase will be different. With SRF and MRF your fluid in the center feels the acceleration immediately, since it is added as a source term (again we are talking about fluid on a spinning plate). While a moving wall velocity only effects the fluid near the wall and everything else feels no force initially. Using boundary conditions becomes however more and more complex if the surface is e.g not round like a cylinder.

Your geometry is however not on a spinning plate, but is stationary with moving walls. Hence in the inertial frame there is no SRF or MRF. The problem is the skrew, a simple boundary condition can not capture it's movement. You need to turn it in the inertial frame and hence move the mesh.
You need to decide which reference frame you want to choose for your simulation. In the inertial reference frame the skew is turning and the outer wall is moving. Hence you could move the mesh accordingly, which is however impossible without remeshing due to the different speeds. You can't use boundary conditions for the skew in the inertial frame, since this won't turn the skew. You can however use a boundary condition for the outer wall due to it's symmetry.

You can also choose a reference frame in which the skew is stationary. In this reference frame you need to add the source terms from SRF or MRF. And add the velocity of the outer wall as a boundary condition.

[decanter]

Thank you so much for your detailed explainations. It helped me to visualise the issue and I think I understand it better now.

Originally Posted by Bloerb

https://caefn.com/openfoam/fvoptions-top
You can also choose a reference frame in which the skew is stationary. In this reference frame you need to add the source terms from SRF or MRF. And add the velocity of the outer wall as a boundary condition.

Do you have any idea how I could add these source terms? Before your replies I searched for adding centrifugal and Coriolis forces in fvOptions as my supervisor advised me. I came across with the tabulated accelaration term. (https://www.openfoam.com/documentati...eleration.html). It is stated that to the term is used to simulate the fluid flow in a domain that is in 6-DoF solid-body motion without dynamic mesh by adding the fictitious force terms, e.g., the Coriolis, Centrifugal and Euler forces in a non-inertial reference frame. (https://caefn.com/openfoam/fvoptions-top)

I am not sure if it is the right approach though.

Best regards,
Ayca

[Bloerb]

You do not need to add any additional source terms! You need to make sure to pick the correct boundary conditions.



SRF/MRF adds source terms, since it is used to account for a rotating reference frame. You can't pick a reference frame that suits both rotations, it does not exist. You need to pick one and account for the rest via a boundary condition.
If looking at your setup from an inertial frame. (You looking at it from the outside) you won't have any source terms. The fluid in the center of the turbine will only feel an acceleration due to the shear forces etc acting on it from the walls. To pick the correct boundary conditions for that however you'd need to move your mesh (due to the skew / the outer wall is fine as its rotation does not change your domain in any way so a boundary condition suffices). To switch to a rotating frame you use SRF/MRF. Afterwards you need to pick the correct boundary conditions for the reference frame.

[decanter]

Originally Posted by Bloerb

You do not need to add any additional source terms! You need to make sure to pick the correct boundary conditions.



SRF/MRF adds source terms, since it is used to account for a rotating reference frame. You can't pick a reference frame that suits both rotations, it does not exist. You need to pick one and account for the rest via a boundary condition.
If looking at your setup from an inertial frame. (You looking at it from the outside) you won't have any source terms. The fluid in the center of the turbine will only feel an acceleration due to the shear forces etc acting on it from the walls. To pick the correct boundary conditions for that however you'd need to move your mesh (due to the skew / the outer wall is fine as its rotation does not change your domain in any way so a boundary condition suffices). To switch to a rotating frame you use SRF/MRF. Afterwards you need to pick the correct boundary conditions for the reference frame.

I really apperiate your thoughts and help, sorry if I am asking too much now but I really feel stuck at this point. I will check if I get it correctly with a concrete example:

We assume that the screw rotates with 2200 rpm (230 rad/s) around x-axis and drum with 2000 rpm (209 rad/s). The difference is 200 rpm (21 rad/s).
You said that we can choose a reference frame in which the screw conveyer is stationary. That means that the screw is actually rotating but with the same speed so that it looks like stationary in that frame. For that I think I need to use noslip condition for the screw conveyer. (?) My SRFProperties would look like:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  7
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      SRFProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

SRFModel        rpm;

origin          (0 0 0);
axis            (1 0 0);

rpmCoeffs
{
    rpm             21; // 2200 rpm = 230 rad/s 
}


// ************************************************************************* //

If I understood you correctly I should set the boundary condition of outer wall as rotatingWallVelocity. Is the wall in the reference frame as well? If it is in that reference frame I should then set the velocity -200 rpm (-21 rad/s) (?).

bowl
    {
        type            rotatingWallVelocity;
        origin          (0 0 0);
        axis            (1 0 0);
        omega         -21; //rad/s
        relative        yes;
    }
screw
{
        type            noSlip;
 }

Can I then capture the forces from both rotations (screw and bowl) in the fluid domain?

Best regards,
Ayca

[Bloerb]

SRF rotates everything. Not just a zone, hence also inlet/outlet/wall patches. You need to be precise about inlet and outlet boundary conditions as well.
These BC might be helpfull:

• rotatingPressureInletOutletVelocity
• rotatingTotalPressure
• SRFVelocity
• SRFWallVelocity -- sets the velocity to omega*r (with r= distance of the mesh point to the rotation center)
• SRFFreestreamVelocity

Example for walls from the SRF tutorial case:

    innerWall <--the rotating mixer
    {
        type            noSlip; <-since it's rotating. Hence zero in rotatingFrame
    }
    outerWall <--the stationary wall
    {
        type            SRFVelocity; <--the same as SRFWallVelocity. Zero in interitalFrame hence applies omega*r
        inletValue     uniform (0 0 0);
        relative        no;
        value           uniform (0 0 0);
    }

In SRF you are setting conditions for Urel...so the velocity in that moving reference frame, not the inertial U. Hence the velocity of rotatingWallVelocity is applied for Urel. The skew is noSlip or zero. Your bowl needs to have the correct velocity for Urel. So yes you are correct as far as i can tell. And you should be able to capture all forces. Your feedPipe might be wrong though

[decanter]

Hey again!

First of all thank you, I could run some simulations with the information you gave me. There is a weird thing when I compared results so I wanted to discuss here again.

I first run simulations on a splified geometry by leaving out the feed pipe and accelaration zone. So it is basicly coaxially rotating outer cylinder(drum) and screw with inner wall. I used cyclic inlet and outlet. In the case the reference frame is rotating with 209 rpm. The screw (with innerwall) is supposed to rotate with 230 rpm (absolute) and the drum is rotating with 209 (like reference frame). I used noslip for outer and rotatingWallVelocity for the screw. The weird thing is that depending on how I define the rotatingWallVelocity (relative = yes/no) the results look different. (See the screenshots from Paraview for the same time step)

BC for Urel, when rotatingWallvelocity is given as absolute value:

boundaryField
{
    inAMI
    {
        type            cyclicAMI;
        value          uniform (0 0 0);
    }
    outAMI
    {
         type            cyclicAMI;
         value           uniform (0 0 0);
    }

   drum
    {
        type            noSlip;
    }

    screw
    {
        type            rotatingWallVelocity;
        relative        no;
        origin          (0 0 0);
        axis            (1 0 0);
        omega           230; //rad/s            
    }
    innerwall
    {
        type            rotatingWallVelocity;
        relative        no;
        origin          (0 0 0);
        axis            (1 0 0);
        omega           230; //rad/s
    }
}

BC for Urel, when rotatingWallvelocity is given as relative value:

boundaryField
{
    inAMI
    {
        type            cyclicAMI;
        value          uniform (0 0 0);
    }
    outAMI
    {
         type            cyclicAMI;
         value           uniform (0 0 0);
    }

   drum
    {
        type            noSlip;
    }

    screw
    {
        type            rotatingWallVelocity;
        relative        yes;
        origin          (0 0 0);
        axis            (1 0 0);
        omega           21; //rad/s            
    }
    innerwall
    {
        type            rotatingWallVelocity;
        relative        yes;
        origin          (0 0 0);
        axis            (1 0 0);
        omega           21; //rad/s
    }
}

Do you have any idea?

Thanks in advance.

[Bloerb]

The boundary condition rotatingWallVelocity does not have a relative option? Hence this shouldn't do anything. Please try renaming yes to banana und run the code. This shouldn't stop the solver and hence the option isn't read

https://github.com/OpenFOAM/OpenFOAM...hVectorField.H