strange behaviour in the "interface" between two reference frames (simpleFoam MRF)

cvillescas · December 3, 2015, 11:59

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

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

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

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

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

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

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

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

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

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?

August 17, 2016, 11:50		#9
cvillescas New Member Carla Join Date: Jun 2015 Posts: 16 Rep Power: 11	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((nuEffdev2(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!! Alisa_W likes this.

August 18, 2016, 08:24		#12
cvillescas New Member Carla Join Date: Jun 2015 Posts: 16 Rep Power: 11	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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LEMOS InflowGenerator	r_gordon	OpenFOAM Running, Solving & CFD	103	December 18, 2018 01:58
OpenFOAM 1.6 ext - Compilation errors - Fedora 17(32bit)	toolpost	OpenFOAM Installation	15	September 21, 2012 10:38
error message	cuteapathy	CFX	14	March 20, 2012 07:45
G95 + CGNS	Bruno	Main CFD Forum	1	January 30, 2007 01:34
Two-Phase Buoyant Flow Issue	Miguel Baritto	CFX	4	August 31, 2006 13:02

August 17, 2016, 04:57		#3
cvillescas New Member Carla Join Date: Jun 2015 Posts: 16 Rep Power: 11	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.

August 17, 2016, 10:32		#6
cvillescas New Member Carla Join Date: Jun 2015 Posts: 16 Rep Power: 11	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.

August 17, 2016, 10:44		#7
cvillescas New Member Carla Join Date: Jun 2015 Posts: 16 Rep Power: 11	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

August 18, 2016, 03:53		#11
MBttR Member Bruno Join Date: Jun 2016 Location: Siegen, Germany Posts: 59 Rep Power: 10	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

August 18, 2016, 08:40		#13
davidtran New Member DavidTran Join Date: Aug 2016 Posts: 10 Rep Power: 10	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,

August 22, 2016, 05:05		#16
cvillescas New Member Carla Join Date: Jun 2015 Posts: 16 Rep Power: 11	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

July 27, 2021, 11:05		#18
chakshu New Member Chakshu DEORA Join Date: Jun 2021 Posts: 21 Rep Power: 5	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?