[Jetfire]

Originally Posted by Tobi

Hi,

my simulations are running on 40 cores 2 weeks ...
But you time step is very small and your density is wrong (I think)

rho max/min : 2 0.5

you make something wrong.
I dont know what because you do not share many details. You should check out you time steps... maybe your pressure, velocity, k, epsilon are expoding. As I can see, you should use the correct form of the PIMPLE algorithm. Maybe it will be stabilized. Checkout my blog or also available at the wiki.

Hi tobi,
My density is calculated based on inlet pressure and inlet temperature and it is 1.1845kg/m3. I have taken the FvSchemes and FvSolution files from the annularThermalMixer Tutorial under rhoPimpleDyMFoam as i am using the same solver and modified them. Can you please explain what values i should be giving for rho max/min: for my case.

My time step is calculated using courant no. formula co=delT*U/delX
I have set co max=1, my maximum velocity =78m/sec calculated using v = w*r
w=31415 rad/sec , radius of impeller r = 5cm. min cell volume from my mesh is 5.37e-16 so delX is approx =8e-06, delT i found is 5.2e-09.Is this the right approach???

I have invested a lot of time in setting up my boundary conditions in the 0 folder.
Attached is my 0 folder , please take a look and correct me if there is anything wrong.

You can also find detailed explaination of my simulation in this thread http://http://www.cfd-online.com/For...ledymfoam.html

Thanks

[Tobi]

Originally Posted by Jetfire

You can also find detailed explaination of my simulation in this thread http://www.cfd-online.com/Forums/openfoam-solving/143340-compressor-simulation-using-rhopimpledymfoam.html

Thanks

Why do you make double posts?

@Bruno - please move all posts refered to Jetfire question to the given thread.
@Jetfire - double posts are not wished

I will answer you in your thread!


PS your link is wrong

[Jetfire]

Sorry.

The correct link is
http://www.cfd-online.com/Forums/ope...ledymfoam.html

[RodriguezFatz]

Hi,
Since Tobias uses this solver he will probably be the better contact, but here are some general things:

1. Your omega equation is bounded, this is not good. You need to find the source of that. I would try to use "Gauss linear uncorrected" for the laplacian scheme (at least for omega equation).
2. You run many solvers without any iteration. I would reduce the tolerance (if needed) or just reduce the number of innner iterations of the solver.
3. Your first pcorr solving takes 49 iterations. I don't think this is good.
4. You have a max Co number of 1. I don't think this is needed for solver "PIMPLE". Also the average Co is 1e-4. Thus, your mean flow moves 10000 times slower than in the fast / small cells. Can you try to spot the high Co cells and try to modify them, so Co gets smaller there?

[Tobi]

Hello,

some hints and question:

• I did not read the above things but are you familiar with openFOAM?
• In my simulations the target and source faces are always the same for the AMI interface. In your case there are significant differences
• Which density do you expect? I ask because your solver calculates higher and lower densitys that you wish to have. Therefor you cut it:

// Recalculate density from the relaxed pressure
rho = thermo.rho();
rho = max(rho, rhoMin);
rho = min(rho, rhoMax);
rho.relax();

Calculation is done in pEqn.H and you can see it out of your output

rhoEqn max/min : 2.15688 0.182153 .
.
GAMG:  Solving for p, Initial residual = 1.49854e-09, Final residual = 1.49854e-09, No Iterations 0 
rho max/min : 2 0.5  // CUTTED

That is because you set your min and max values in your fvSolution:

    rhoMin          rhoMin [ 1 -3 0 0 0 ] 0.5;     
    rhoMax          rhoMax [ 1 -3 0 0 0 ] 2.0;

Additionally you have problems with your omega (bounding extrem).
As I told you befor, you should use the correct PIMPLE ALGO with underrelaxation. I refer (again) to my blog or to the wiki. There you will get how to set up these parameters:

PIMPLE 
{
     momentumPredictor   yes;
     transonic           no;
     nOuterCorrectors    1;
     nCorrectors         3;
     nNonOrthogonalCorrectors 1;
.
.
.
    residualControl {} ... 
}

I suspect that you AMI interface is wrong

AMI: Creating addressing and weights between 1900 source faces and 32076 target faces 
AMI: Patch source sum(weights) min/max/average = 0.99546, 1, 0.999763 
AMI: Patch target sum(weights) min/max/average = 0.467982, 1, 0.996805 
AMI: Creating addressing and weights between 17748 source faces and 5456 target faces 
AMI: Patch source sum(weights) min/max/average = 0.538509, 1.06046, 1.00015 
AMI: Patch target sum(weights) min/max/average = 0.685009, 1.00305, 0.999864 
AMI: Creating addressing and weights between 17839 source faces and 1957 target faces 
AMI: Patch source sum(weights) min/max/average = 0.86998, 1, 0.999108 
AMI: Patch target sum(weights) min/max/average = 0.991279, 1, 0.99992

Never had something like that. Do you have more rotating zones?
Did you ever checked out if your mesh is okay?

checkMesh -constant

And did you ever control your AMI ?

moveDynamicMesh -checkAMI

• change your smoother to PBiCG
• If you are not certain which scheme you should use, first try always UPWIND, the reason is the physics! you can find a lot of schemes on my homepage.
• Linear is always very unstable
• linearUpwind can produce also unphysical values

[Jetfire]

Hi Tobi,
Thanks for your reply

Meshing was done using ANSYS ICEM CFD and the simulation was already run on CFX which gave good results.My task is to simulate the same on OpenFOAM.

Did you ever checked out if your mesh is okay?

Yes checkMesh was OK

I have even checked whether my AMI Interfaces were correct using moveDynamicMesh -checkAMI and it had run without any errors. Checked the compressor rotation on ParaView and the rotation was fine.

Coming to my AMI Interfaces , i too have noticed that weights are not 1:1
but that is due to one interface on compressor being meshed with hex and it's neighbour interface on volute being meshed with tet elements. But as long as there is some weight matching the weight on target faces it is fine. This is not a problem as i have checked with moveDynamicMesh -checkAMI and it ran perfectly , otherwise i would have got errors there itself.

Please look at the mesh domain i have posted earlier in this thread.There is only one rotating zone but there are 3 interfaces.
1. inlet and rotor
2.rotor and volute
3.connection between volute and outlet

[Tobi]

Originally Posted by RodriguezFatz

Hi,
Since Tobias uses this solver he will probably be the better contact, but here are some general things:

1. Your omega equation is bounded, this is not good. You need to find the source of that. I would try to use "Gauss linear uncorrected" for the laplacian scheme (at least for omega equation)

Maybe Gauss linear limited corrected 1 should be the better choice. Uncorrected should always applied if you have a very good hex mesh.

-> red Line is wrong (SEE BELOW)

Originally Posted by RodriguezFatz

1. You have a max Co number of 1. I don't think this is needed for solver "PIMPLE". Also the average Co is 1e-4. Thus, your mean flow moves 10000 times slower than in the fast / small cells. Can you try to spot the high Co cells and try to modify them, so Co gets smaller there?

Of course it is needed but as we all can see he is not using PIMPLE algorithm. He is using PISO!

[Tobi]

Hi,

good to know, well done.
So then its clear that you have different faces.
But you are not using PIMPLE as I told you 2 times befor. Have a look into the blog, wiki.

Create mesh for time = 0  

Selecting dynamicFvMesh solidBodyMotionFvMesh 
Selecting solid-body motion function rotatingMotion 
Applying solid body motion to cellZone FLUID_ROTOR  PIMPLE: 

Operating solver in PISO mode

[RodriguezFatz]

Originally Posted by Tobi

Maybe Gauss linear limited corrected 1 should be the better choice.

Do you mean "Gauss linear limited 1"?

Originally Posted by Tobi

Uncorrected should always applied if you have a very good hex mesh.

I don't agree on that. If you have stability problems like we see here, you need to find the source. And since "corrected" scheme is unbounded this is a pretty common source for these omega-bounding errors. Trying "uncorrected" will indeed be much more imprecise but at (possibly) at least not result in negative, unphysical omega values.

[RodriguezFatz]

Originally Posted by Tobi

Of course it is needed but...

Is this a typo?

[Jetfire]

Hi tobi,
I do not know what min or max rho for which calculation be done
So according to you do i have to remove these lines from the pEqn.H file???

rho = thermo.rho();
rho = max(rho, rhoMin);
rho = min(rho, rhoMax);
rho.relax();

And also remove these line from my FvSolution file?

 rhoMin          rhoMin [ 1 -3 0 0 0 ] 0.5;
 rhoMax         rhoMax [ 1 -3 0 0 0 ] 2.0;

Ok. I will refer your blog on how to set up the right settings for PIMPLE ALGORITHM and also for right schemes.

[Tobi]

Hi Phillip,

sorry my fault (:
I mixed the things up!

• corrected = unbounded
• uncorrected = bounded
• limited = blend between the above mentioned

I wanted to say to use that one:

Gauss linear limited 1  =  Gauss linear uncorrected

To the Co - number:

• you need it to control your timestep
• I agree that you should check your mesh and modify it if you have some bad cells that generate high "Co" numbers --> maxCo and averaged as you mentioned
• But first, he should use the pimple algorithm instead of PISO. Its clear that if you use PISO mode you always have small time steps. At least I think Co = 1 for PISO is too high.

[Tobi]

Originally Posted by Jetfire

Hi tobi,
I do not know what min or max rho for which calculation be done
So according to you do i have to remove these lines from the pEqn.H file???

rho = thermo.rho();
rho = max(rho, rhoMin);
rho = min(rho, rhoMax);
rho.relax();

And also remove these line from my FvSolution file?

 rhoMin          rhoMin [ 1 -3 0 0 0 ] 0.5;
 rhoMax         rhoMax [ 1 -3 0 0 0 ] 2.0;

Ok. I will refer your blog on how to set up the right settings for PIMPLE ALGORITHM and also for right schemes.

No you do not have to remove.
First you calculate your density:

rho = thermo.rho()

Then you bound your density with:

rho = min(rho, rhoMax)

That means that if you calculated to high and to low values for rho than you expect (you set it in fvSolutions) then the solution is cutted. Means:

rho = 0.43 » 0.5
rho = 2.13 » 2.0

If the values are correct you have to change the cutted parameter in the fvSolution!
At least - please read the blog or wiki for PIMPLE!

[Jetfire]

Hi,

I have nowhere mentioned PISO algorithm, i dont understand why it is running it in PISO.Can you help me understand what changes i have to make to run it on PIMPLE.

[RodriguezFatz]

It's the "nOuterCorrectors". If set to "1", this is the same as running PISO algorithm. If set >1, it actually runs in real PIMPLE mode.

Solver PIMPLE solves multiple iterations of solver PISO during each time-step. So, if you just solve a single iteration of PISO (nOuterCorrectors=1) each time-step this comes up to PISO.

[Jetfire]

I am not able to open your blog , i get this

Your host needs to use PHP 5.3.10 or higher to run this version of Joomla!

[Tobi]

Originally Posted by RodriguezFatz

It's the "nOuterCorrectors". If set to "1", this is the same as running PISO algorithm. If set >1, it actually runs in real PIMPLE mode.

At least I mentioned it 4 times now!
If you want to use PIMPLE and how it is working - go to my blog. I think you are too lazy to click on my blog on the left of that post so I be kind:

BLOG

WIKI

I hope you will check it out now. There is everything mentioned - also like Philipp told you! You do not use the PIMPLE loop due to your settings in your fvSolution.

Blog is on cfd-online

[Jetfire]

Checking it now

I really thank you both for taking out your precious time and helping me out.
Thanks a lot!

[RodriguezFatz]

Does the omega-bounding vanish, if you use the laplacian-setting I suggested?

[Jetfire]

Hi,
Sorry for the late reply , i was not at the work station

for the rhomin/max , with reference to the air properties at atmospheric pressure in the link http://www.engineeringtoolbox.com/ai...ies-d_156.html
I think my rhomin/max should not exceed the limits 0.524/2.793. But looking at the output there are timeSteps deviating from this for example.

rhoEqn max/min : 2.15688 0.182153 . . GAMG:  Solving for p, Initial residual = 1.49854e-09, Final residual = 1.49854e-09, No Iterations 0  rho max/min : 2 0.5

Why is this happening ? any idea.