Hey jetfire, maybe we can speed up this a little. If you want that,
1) post some log output (one time step is enough)
2) how do you decompose?
3) post your current solver settings (fvSolution)

Please notice that in 300.000 rpm your pressure is not 1bar ...
The density changes due to pressure too! Can you check which pressure you will have in between your blades? I dont know which model you are using but the ideal gas rule is:




means its proportional to

• p = konst, and T increase --> rho decrease (like your table) and vice versa

• p increase and T constant --> rho increase and vice versa

• p and T not constant - depend on the ratio

As I expect, your rotor gives a high partial vacuum -> very small densities!
That is the reason (in my opinion) why your density is in that range. Therefor you should decrease your rhoMin to 0.1 or whatever.

@Tobi: Thanks for the clarification.

@Tobi,


Thanks for the tips to speeden up my simulation, I will try implementing them and let you know the results.

Can you message me your email id , i will send my output log file to you. Cannot post it here as it is exceeding max file size.

Its sufficient if you post only the last time step with all pimple loops like Philipp told. As you see we both had the same thoughts :)

1. Please find the output for 2 timeSteps in attachments

2. I am using hierarchical decomposition with 8 cores.
3. FvSolution

That is not useful.
Please show us the output of your decomposition:
In your case, copy paste your project, decompose it again, store the output and publish it. After that you can remove your copy folder again.

fvSolution:
Was mich aber grad etwas stört ist deine Massenerhaltung:
How many time steps did you calculate since now?
Please check your logfile with pyFoam (pyFoamPlotWatcher).

Additionally you can check your meshCourantNo if you insert "checkMeshCourantNo true" into the PIMPLE directory of your fvSolution. I think it is possible to increase your maxCo no to 3.

I have the output of decomposePar on my terminal , here it is

Hi,

That is not well decomposed. As you can See its not really weighted. Other strategy would be much better, decompose your case only in x direction (if x is the length of your your pump).

Additionally after decomposing, renumbering!

@Tobi

Here is my complete domain

http://www.cfd-online.com/Forums/ope...tml#post515511

Since large no. of elements are there in all 3 directions i have given '(2 2 2)' to make it 8 cores. The similar decomposition method is used for Propeller tutorial which is similar to my case. Please see the domain and let me know if i have to change the decomposition approach or change the subdomains.

Jetfire, did you try to use some other decomposition method? I had a very simple pipe flow and thought it is a clever idea to use "simple" decomposition. It showed low number of shared faces and all that stuff, but for some reason it was slower than just using "scotch" without any additional settings. You can just try some different methods and write down the different execution times. It's worth it for such long simulations to try a bit at the beginning.

Just a general question: Why is every time step converged to insanity? I mean, do you really get different results for these kind of problems with 30 pimple loops compared to - let's say a 3 times smaller time step and PISO solver (thus 1 outer iteration per time step)? Your Courant number is close to "1" anyway, so for stability of PISO just a slightly smaller time step would be needed. All the LES guys use PISO... is this that much different from what you are doing?

Also: Why the first pressure corrector with 60 iterations? For me, this looks like something is going utterly wrong. I think each linear solver should not take more than just a few iterations. Maybe this is again due to your solver, but please can someone elaborate this?

Another point is: Did you try different settings for the GAMG solver? I did this for a case of mine and found out that playing with "mergeLevels" decreased the simulation time (in my case "2" was the best). Also changing the pre,post,finest sweeps settings changed a lot:
This was the best for me.

I did not get the point. Co should be increase to 2 during simulation (if it is set in the controlDict), you also can set it to 3 or 4 to get bigger time steps (depend on your relax factors also). But why should he use PISO? It would be much more expensiv and maybe not stable.

I dont know which time step iteration is used but at the beginning in such chases it could be normal. Sometimes I also get 100 iterations for the pressure equation. Depend on the system and I never had rpm 300.000.

If you get 1000 Iterations something is wrong.
In the pressure calculation (my experience) it could occur. But it also could be possible that the BC are wrong for that problem. However, I first should have a look at the calculation procedure in that solver but there is not time for that now.

My hints to you:

• move your mesh that the long pipe is colinear with the z-axis (transform points)

• then use manuelDecomposition

• If its to complex try using scotch and have a look to the meshes

@Philipp, here in our institute we get the best results with simple or hierarchical instead of scotch. The gain was round about 13% because scotch decomposed our mesh in a very strange way.

Ok, the point was: Even with Co=3 or 4 and like 25 outer iterations I don't see a reason to use PIMPLE. In such cases, one PIMPLE time step would be like 25 PISO time steps, right? So, if you can reduce the time step by a factor of - let's say 8 - to get a Co of 0.5 and use PISO, you still have less computational time to spend. And you have a much finer time resolution.

Or is this just a matter of initialization? Does the number of PIMPLE loops decrease drastically after a few time steps?

Is there a paper who say that 25 PISO steps = 1 PIMPLE loop (with 25 iterations). In my opinion its not true because you can not compare the algorithms directly.

You are right, the time resolution would be better. But you have to check what is necessary in your case. So lets say you want simulate 1s and your mesh is big and the system is very stiff you. Therefor you have to set Co to (lets say) 0.3 to be stable. Therefor you will get a dT = 1e-9 which is very bad in that case. Also if there is one cell which makes trouble, this cell would reduce the whole time step, maybe to 1e-11 till it will crash. With relaxation you can handle this better.

• well you are right you are more accurate in time

• But if you have some problem cells that will reduce the time to 1e-11 its bad.

It is definitiv also an initialization and boundary problem. If the boundary are bad defined or wrong, all algorithm will blow up or crash. The outer iterations will decrease during time steps. Sometimes I have loops like 80 at the beginning and after a few timesteps I get 8 - 10 and my timestep is much bigger than PISO. The computational costs decrease and the linear system is stable due to under-relaxation.

If there would be no advantage of PIMPLE compared to PISO then nobody would use PIMPLE.

I got the feeling that he doesn't use the advantage of PIMPLE if he iterates more often than the number of PISO steps he actually needs if he reduces the time step. This is just an educated guess, I never tryed it.

He also can try something like that:

• nOuterCorrection 3;
• nCorrections 2;

Then the first 2 iterations are relaxed and the last one is without relaxation. But this could give stability problems because its relativ similar to PISO then but with 2 relaxation iterations. I am not sure if this case is working without relaxation. He can also switch to PISO again but then he should use maxCo 0.1 - 0.7 but not 1.

I can not test the case because I do not have it (:

Question: are you using the boundary condition which you attached in this post: http://www.cfd-online.com/Forums/ope...tml#post516087

The reason why I ask is due to the U - file, if it is like that you have an error which could be the reason of the pcorr iteration.


That could be possible. I will check if I find some papers about that.

Hi,

Bad news , Simulation crashed showing the same error as posted earlier after few timeSteps. check the output in attachments

• Is this problem related to my thermoPhysicalProperties ? should I change my thermoPhysical settings?

@Tobi do not refer to those boundary conditions, those were from annular thermal mixer tutorial, I am attaching my final 0 folder for your reference, do let me know if you need any other details.