CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   strange behaviour in the "interface" between two reference frames (simpleFoam MRF) (https://www.cfd-online.com/Forums/openfoam-solving/163664-strange-behaviour-interface-between-two-reference-frames-simplefoam-mrf.html)

cvillescas December 3, 2015 11:59

strange behaviour in the "interface" between two reference frames (simpleFoam MRF)
 
1 Attachment(s)
Hi Foamers!

I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help.

I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF).

My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area.

By the way, I am using OpenFoam-3.0.

Anyone can tell me what is wrong with the simulation? Thank you.

Carla

0/U file:
Code:

#include "../system/runConditions"

dimensions      [0 1 -1 0 0 0 0];

internalField  uniform $flowVelocity;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value          uniform $flowVelocity;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value          uniform (0 0 0);
    }
    propeller
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }
    outerCylinder
    {
        type            symmetry;
        // value          uniform $flowVelocity;
    }
}

0/p file:
Code:

#include "../system/runConditions"

dimensions      [0 2 -2 0 0 0 0];

internalField  uniform $pressure;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value          uniform $pressure;
    }
    propeller
    {
        type            zeroGradient;
    }
    outerCylinder
    {
        type            symmetry;
    }
}

Boundary file:
Code:

4
(
    inlet
    {
        type            patch;
        nFaces          448;
        startFace      1688089;
    }
    outlet
    {
        type            patch;
        nFaces          448;
        startFace      1688537;
    }
    propeller
    {
        type            wall;
        inGroups        1(wall);
        nFaces          16167;
        startFace      1688985;
    }
    outerCylinder
    {
        type            symmetry;
        inGroups        1(symmetry);
        nFaces          2304;
        startFace      1705152;
    }

And MRFproperties file:
Code:

MRF1
{
    cellZone    cellZoneCyl;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches (inlet outlet outerCylinder);

    origin    (0 0 0);
    axis      (1 0 0);
    omega    627.1247;
}


davidtran August 17, 2016 03:42

Hi,

I am testing simple geometry using MRFSimpeFoam and AMI interface. However, my solution was diverged due to a large value of "time step continuity errors". I wonder if you can share your experience to solve this issue.

I looking forward to hearing from you soon.

Quote:

Originally Posted by cvillescas (Post 576079)
Hi Foamers!

I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help.

I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF).

My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area.

By the way, I am using OpenFoam-3.0.

Anyone can tell me what is wrong with the simulation? Thank you.

Carla

0/U file:
Code:

#include "../system/runConditions"

dimensions      [0 1 -1 0 0 0 0];

internalField  uniform $flowVelocity;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value          uniform $flowVelocity;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value          uniform (0 0 0);
    }
    propeller
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }
    outerCylinder
    {
        type            symmetry;
        // value          uniform $flowVelocity;
    }
}

0/p file:
Code:

#include "../system/runConditions"

dimensions      [0 2 -2 0 0 0 0];

internalField  uniform $pressure;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value          uniform $pressure;
    }
    propeller
    {
        type            zeroGradient;
    }
    outerCylinder
    {
        type            symmetry;
    }
}

Boundary file:
Code:

4
(
    inlet
    {
        type            patch;
        nFaces          448;
        startFace      1688089;
    }
    outlet
    {
        type            patch;
        nFaces          448;
        startFace      1688537;
    }
    propeller
    {
        type            wall;
        inGroups        1(wall);
        nFaces          16167;
        startFace      1688985;
    }
    outerCylinder
    {
        type            symmetry;
        inGroups        1(symmetry);
        nFaces          2304;
        startFace      1705152;
    }

And MRFproperties file:
Code:

MRF1
{
    cellZone    cellZoneCyl;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches (inlet outlet outerCylinder);

    origin    (0 0 0);
    axis      (1 0 0);
    omega    627.1247;
}



cvillescas August 17, 2016 04:57

Hi davidtran,

I am not sure I understand what you are trying to achieve. As fas as I am aware, you don't need to use AMI with MRFsimpleFoam (what OF version are you using?). AMI is used when you've got a part of the mesh moving and a stationary one. In MRFsimpleFoam nothing is moving, simply Navier Stokes equations are solved in two different reference frames: for the cells in the rotating region (which are defined by a cellZone in OF) NS equations are solved in a rotating reference frame, and for the cells outside the rotating region, stationary (same as ever) NS equations are solved.

Regarding my issue I had to refine more the rotating region and the region around the rotating region. But I am not sure you've got the same issue. If you could post your case I might be able to tell if it's the set up, mesh, boundary conditions or numerics what is causing your divergence.

davidtran August 17, 2016 09:43

Hi cvillescas,

Thank you for your response.
I want to perform MRFSimpleFOAM with AMI because the convergence result of MRF simluation will be used for unsteady simulation later (pimpleDyMFoam solver). I think that AMI technique is to interpolate flux between two interfaces of different fluid region. So it does not matter as a fluid domain is modeled as rotationary or stationary. Am I right?
I uploaded both cases including MRFSimpleFoam only and MRFSimpleFoam with AMI interface. Both of them was not converged. Please help me figure out the problem.

1. MRFSimpleFoam only
https://www.dropbox.com/s/xs3ooxsjdw...ly.tar.gz?dl=0
2. MRFSimpleFoam with AMI interface
https://www.dropbox.com/s/r8jcnssyw4...am.tar.gz?dl=0

I looking forward to hearing from you.


Quote:

Originally Posted by cvillescas (Post 614317)
Hi davidtran,

I am not sure I understand what you are trying to achieve. As fas as I am aware, you don't need to use AMI with MRFsimpleFoam (what OF version are you using?). AMI is used when you've got a part of the mesh moving and a stationary one. In MRFsimpleFoam nothing is moving, simply Navier Stokes equations are solved in two different reference frames: for the cells in the rotating region (which are defined by a cellZone in OF) NS equations are solved in a rotating reference frame, and for the cells outside the rotating region, stationary (same as ever) NS equations are solved.

Regarding my issue I had to refine more the rotating region and the region around the rotating region. But I am not sure you've got the same issue. If you could post your case I might be able to tell if it's the set up, mesh, boundary conditions or numerics what is causing your divergence.


blais.bruno August 17, 2016 10:26

Do you still have this problem?

If so,
Can I ask you how do you create your mesh?
I feel like it seems the mesh interface is ill-defined and this is why you get spurious velocities at the interface.
Have you tried using the same mesh for AMI? AMI usually gives you a better idea if somehting is going wrong because you can do a transient analysis and you can also see the mesh motion (which makes everything much more clear).

I suggest you try and design your own 2D test case first before moving to 3D. The tutorials for AMI and MRF are quite poor I find.
I have one lying around for a Taylor-Couette flow, I could try to find it!

Cheers
BB


Quote:

Originally Posted by cvillescas (Post 576079)
Hi Foamers!

I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help.

I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF).

My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area.

By the way, I am using OpenFoam-3.0.

Anyone can tell me what is wrong with the simulation? Thank you.

Carla

0/U file:
Code:

#include "../system/runConditions"

dimensions      [0 1 -1 0 0 0 0];

internalField  uniform $flowVelocity;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value          uniform $flowVelocity;
    }
    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value          uniform (0 0 0);
    }
    propeller
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }
    outerCylinder
    {
        type            symmetry;
        // value          uniform $flowVelocity;
    }
}

0/p file:
Code:

#include "../system/runConditions"

dimensions      [0 2 -2 0 0 0 0];

internalField  uniform $pressure;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value          uniform $pressure;
    }
    propeller
    {
        type            zeroGradient;
    }
    outerCylinder
    {
        type            symmetry;
    }
}

Boundary file:
Code:

4
(
    inlet
    {
        type            patch;
        nFaces          448;
        startFace      1688089;
    }
    outlet
    {
        type            patch;
        nFaces          448;
        startFace      1688537;
    }
    propeller
    {
        type            wall;
        inGroups        1(wall);
        nFaces          16167;
        startFace      1688985;
    }
    outerCylinder
    {
        type            symmetry;
        inGroups        1(symmetry);
        nFaces          2304;
        startFace      1705152;
    }

And MRFproperties file:
Code:

MRF1
{
    cellZone    cellZoneCyl;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches (inlet outlet outerCylinder);

    origin    (0 0 0);
    axis      (1 0 0);
    omega    627.1247;
}



cvillescas August 17, 2016 10:32

That makes sense :) Let's focus on converging the case without AMI and we can move on from there then.

I had a quick look at your case and I reckon your boundary conditions at the inlet are not quite right. If you fix pressure and velocity at the same time the solver might not be able to find a solution that complies with all the restrictions (that would explain the continuity errors). Try zeroGradient for pressure at the inlet.

If you still have problems after this we can have a look at the numerics.

cvillescas August 17, 2016 10:44

Hi Bruno,

I created the mesh with snappyHexMesh and I overcame the problem refining. Also, I later found out that my omega velocity was an order of magnitude greater of what it was meant to be. I reckon decreasing the omega also helped.

Later on, I started using AMI and I started seeing again some spurious velocities, but not as high as the ones I showed here. I've been told GGI in foam-extend is much better than AMI but haven't tried yet. And yes, it would probably be better to study a 2D case first :) Thanks for your answer!

CV

davidtran August 17, 2016 10:49

1 Attachment(s)
Hi cvillescas,

I have followed your guide by changing zeroGradient BC for pressure at the inlet. In addition, I also reduced "relTol" in fvSolution to 1e-5. However, the solution was blow-up at Time = 22. You can see from the attached file.
I looking forward to hearing from you.



Quote:

Originally Posted by cvillescas (Post 614375)
That makes sense :) Let's focus on converging the case without AMI and we can move on from there then.

I had a quick look at your case and I reckon your boundary conditions at the inlet are not quite right. If you fix pressure and velocity at the same time the solver might not be able to find a solution that complies with all the restrictions (that would explain the continuity errors). Try zeroGradient for pressure at the inlet.

If you still have problems after this we can have a look at the numerics.


cvillescas August 17, 2016 11:50

Hi davidtran,

Can you try with this fvSchemes?
Code:

ddtSchemes
{
    default        steadyState;
}

gradSchemes
{
    default        cellLimited leastSquares 1;
}

divSchemes
{
    default        none;
    div(phi,U)                  bounded Gauss linearUpwind grad(U);
    div(phi,k)                  bounded Gauss linearUpwind grad(k);
    div(phi,epsilon)            bounded Gauss linearUpwind grad(epsilon);
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default            no;
    p            ;
}


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

I've changed gradSchemes to leastSuqares because it's more accurate, particularly for tetrahedral meshes, and it doesn't add much computation time. I add the limiter because I've never managed to converge a simulation without the limiter.
I am not 100% sure of this but I think linear scheme is a central differencing scheme, which wouldn't be suitable for velocity. You need and upwind-biased scheme. linearUpwind is as accurate as limitedLinear and is upwind-biased. If this doesn't work, upwind is only first order accurate but will most certainly work. You could run upwind for the first iterations and then switch to linearUpwind.

I hope that helps!!

davidtran August 18, 2016 02:57

Hi cvillescas,

I am sorry for my late response.
Firstly, there is a good new. I got a good convergence as the leastSquares of gradScheme was used only. Now I am trying to test the second case which involves the use of MRFsimpleFoam and AMI interface. In this case, the solution was converged up to roughly 500 time step. After that, it was gradually diverged due to time step continuity error. Any idea?

I looking forward to hearing from you.


Quote:

Originally Posted by cvillescas (Post 614385)
Hi davidtran,

Can you try with this fvSchemes?
Code:

ddtSchemes
{
    default        steadyState;
}

gradSchemes
{
    default        cellLimited leastSquares 1;
}

divSchemes
{
    default        none;
    div(phi,U)                  bounded Gauss linearUpwind grad(U);
    div(phi,k)                  bounded Gauss linearUpwind grad(k);
    div(phi,epsilon)            bounded Gauss linearUpwind grad(epsilon);
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default            no;
    p            ;
}


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

I've changed gradSchemes to leastSuqares because it's more accurate, particularly for tetrahedral meshes, and it doesn't add much computation time. I add the limiter because I've never managed to converge a simulation without the limiter.
I am not 100% sure of this but I think linear scheme is a central differencing scheme, which wouldn't be suitable for velocity. You need and upwind-biased scheme. linearUpwind is as accurate as limitedLinear and is upwind-biased. If this doesn't work, upwind is only first order accurate but will most certainly work. You could run upwind for the first iterations and then switch to linearUpwind.

I hope that helps!!


MBttR August 18, 2016 03:53

Hi Carla,

Do you have experience in varying the domain around the propeller to see how that changes results? I get very different results depending on how far I extend it up- and downstream. Would you mind sharing your case? I also still have some issues with my snappyHexMesh, which I think are memory related. Do you use a .stl cylinder to define the rotating zone? Do you add layers to that or only to the propeller?

Many thanks,
Greetings,

Bruno

cvillescas August 18, 2016 08:24

Hi Bruno,

I saw your question and I think it's a very interesting exercise but I've never studied how the size of the rotating region affects results.

I didn't answer your question because I don't know how to properly explain this, I was hoping some else would. The thing is I went to the last OF workshop and one of the founders and developers of foam-extend said there's a term in the equations (I think is the time derivative of phiCorrect) that is added at a given time step and substracted at the next time step. He said that when you have a rotating mesh, you are adding and substracting different things and you shouldn't be. He said that's the reason why you get different results when you run at different Courant numbers and I think that could be the reason why you are getting different results. Following this reasoning, I would say the smaller the rotating region the better, I don't know if that matches your experience. Do you have experimental data? Are you also simulating a propeller?

I've been trying to find the slides he was putting when he presented this but I haven't, sorry. He also said this would be solved with the next foam-extend release, foam-extend 4.0. It should be released shortly.

Myself I've been focusing on how the numerics affect the results, and at the moment my simulation highly depends on the gradient scheme and limiter that I choose, which is not acceptable. I've tried both rotating mesh and rotating reference frame and I get similar variations in propeller forces depending on the grad scheme and limiter, so the stated above is not the (only) reason why I get bad results. I've uploaded the case here so that you can have a look, If you can spot anything that's wrong please tell me! I've been told it's the mesh but no luck in that front so far. I still have some things to try, though.


And davidtran,

I tried the fvSchemes that I posted here and with the BC for pressure at the inlet of zeroGradient and it runs past the 500 iterations (up to 1000 at least).

If you still want to use your settings, why don't you create the AMI from the converged solution of your run without AMI? I've never done it but it should work. You should be able to do it with
Code:

createBaffles
Code:

mergeOrSplitBaffles -split
There's an examples of createBafflesDict in the case I shared.

davidtran August 18, 2016 08:40

Hi Caria,

Thank you so much for sharing your experience. They help me a lot. I will try to test my simulation based on your comments.

Best regards,

mdgowhar August 18, 2016 09:17

Quote:

Originally Posted by davidtran (Post 614379)
Hi cvillescas,

I have followed your guide by changing zeroGradient BC for pressure at the inlet. In addition, I also reduced "relTol" in fvSolution to 1e-5. However, the solution was blow-up at Time = 22. You can see from the attached file.
I looking forward to hearing from you.

In my experience if you use parallel with MRF, it always diverge.
But with the single core, it gives good converging without any problem.

MBttR August 19, 2016 10:45

Quote:

Originally Posted by cvillescas (Post 614529)
Hi Bruno,

I saw your question and I think it's a very interesting exercise but I've never studied how the size of the rotating region affects results.

I didn't answer your question because I don't know how to properly explain this, I was hoping some else would. The thing is I went to the last OF workshop and one of the founders and developers of foam-extend said there's a term in the equations (I think is the time derivative of phiCorrect) that is added at a given time step and substracted at the next time step. He said that when you have a rotating mesh, you are adding and substracting different things and you shouldn't be. He said that's the reason why you get different results when you run at different Courant numbers and I think that could be the reason why you are getting different results. Following this reasoning, I would say the smaller the rotating region the better, I don't know if that matches your experience. Do you have experimental data? Are you also simulating a propeller?

I've been trying to find the slides he was putting when he presented this but I haven't, sorry. He also said this would be solved with the next foam-extend release, foam-extend 4.0. It should be released shortly.

Myself I've been focusing on how the numerics affect the results, and at the moment my simulation highly depends on the gradient scheme and limiter that I choose, which is not acceptable. I've tried both rotating mesh and rotating reference frame and I get similar variations in propeller forces depending on the grad scheme and limiter, so the stated above is not the (only) reason why I get bad results. I've uploaded the case here so that you can have a look, If you can spot anything that's wrong please tell me! I've been told it's the mesh but no luck in that front so far. I still have some things to try, though.

Hi Carla,

Thanks for the reply. I'm using MRF, not AMI, so I don't think that applies to my case. Good to know in case I do switch to AMI though. I'm just a bit scared a bit about calculation times. I'm not working on a loose propeller, I'm working on a fully modeled quadcopter, with 4 MRF zones. I do have flight data but before even attempting to calibrate/validate, I want to find out how the size of the MRF domain dictates the result. Will keep an eye on it and keep you posted! Will also have a look at your case :)

*edit*
Quickly comparing meshes (I haven't gotten your results in yet) there's some things that may point me in the right direction already. You have a whole lot more domain finely meshed behind the propeller. Obviously, when I increase my MRF domain size, the refinement increases as well, as my refinement is linked to my MRF cylinders, which may cause some of the differences between the cases with different MRF domain sizes. I'd say your domain overall seems relatively small though, meaning the height and width of the bounding box related to the diameter of your propeller. Also, the mesh quality of the propeller seems relatively low? Other random things I notice; Why do you have U=0 fixedValue on the side walls, is this the case in the physical, real-life scenario? Rotation speed really around 600rpm? (I'm not used to ship propellers so could be). Seems so high as U is only 3.6.

cvillescas August 22, 2016 05:05

Hi Bruno,

Thank you for your answer.

Definitely not your case if you are not using AMI, sorry. Good guess with the refinement, that could be it. Let us know if you confirm this.

Thanks for your advice. I will try increasing the domain size and obviously propeller refinement (that was my main front up to now, but I find the quality of the AMI decreases when I refine and my simulation crashes, I might need to define AMI further away from the propeller). I thought I had slip walls on the sides, I don't think it makes much of a difference but thank you for spotting that. In the experiments they do have walls but I don't want to be simulating that. And yes, rotation speed is 600rpm and is a normal speed for a marine propeller, you could even have 1000rpm.

Carla

cfd_user_pune October 3, 2019 13:41

Quote:

Originally Posted by cvillescas (Post 614385)
Hi davidtran,

Can you try with this fvSchemes?
Code:

ddtSchemes
{
    default        steadyState;
}

gradSchemes
{
    default        cellLimited leastSquares 1;
}

divSchemes
{
    default        none;
    div(phi,U)                  bounded Gauss linearUpwind grad(U);
    div(phi,k)                  bounded Gauss linearUpwind grad(k);
    div(phi,epsilon)            bounded Gauss linearUpwind grad(epsilon);
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default            no;
    p            ;
}


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

I've changed gradSchemes to leastSuqares because it's more accurate, particularly for tetrahedral meshes, and it doesn't add much computation time. I add the limiter because I've never managed to converge a simulation without the limiter.
I am not 100% sure of this but I think linear scheme is a central differencing scheme, which wouldn't be suitable for velocity. You need and upwind-biased scheme. linearUpwind is as accurate as limitedLinear and is upwind-biased. If this doesn't work, upwind is only first order accurate but will most certainly work. You could run upwind for the first iterations and then switch to linearUpwind.

I hope that helps!!


Thanks. Your suggestions worked for me
Cheers,

chakshu July 27, 2021 11:05

Hello,

I think I am facing the same issue. I am trying to simulate a propeller using MRF +simpleFoam. I have described my problem in this post. I am getting zero velocity field outside the whole domain except on the blade.

My question is do we need some kind of interface between MRF zone and statioanry zone? Normally, I was thinking we don't need it but seeing the results I think I am missing something. Any comments?


All times are GMT -4. The time now is 08:37.