pressure eq. "converges" after few time steps
 

Hi everybody,
weird simpleFoam convergence over here, need your help!
I have a complex pipes geometry, similar to what sketched in the geom.png file. The two main pipes are connected by fans to the outside, which is represented by a spherical domain. Reynolds is around 21000 on the smallest pipe, thus a launderSharmaKE model is applied, using wallfunction to keep low the cell number. In any case, the mesh is not really fine since I first want to evaluate my setup. BC are standard:

• external domain:
  • U, epsilon, k inletOutlet;
  • p fixedValue 0;
• pipes:
  • U: fixedValue;
  • epsilon, k wallFunction;
  • p zeroGradient;

fvSchemes is as follow:
while I tried different combinations for fvSolution:
and the second one:
I ended up with this log file:
Does this implies that the pressure is already converged at the second time step??? :eek:
This does not change when:
- reducing the nNonOrthogonalCorrectors;
- using the second fvSchemes files;
- switching off the turbulence.

Any explanation on that? Really no ideas...

thank you!

maddalena

Hi,


try lowering the tolerances of the linear solvers. Something in the order of 1e-12 might be appropriate.

Remember, your simulation is not converged if the residuals of just one equation fall below a certain tolerance. The pressure field depends on the velocity field and vice versa - since your velocity field clearly hasn't converged after the second iteration your whole problem hasn't (would be very surprising if it had) and the pressure equation might and probably will be re-solved at some point.


Greetings,
Felix.

Dear Maddalena,

I would try also changing the initial conditions: I am not aware of your problem but maybe you can try to force the raising of pressure gradients by assigning non zero values for the velocity in the pipes and zero outside.

Regards,

Franco

Thanks Felix and Francesco for your suggestions.
Some observations after some more try:
That helped a lot. Now I have p and U equations that are solved at every time step.
Yes, of course I have a feeling of this. But is it correct to first solve U equation and than, after some time, solve p? Is this not longer than solve all the equations at the same time?
About the boundary conditions I am almost sure that everything is fine, since I have already used this setup in the past. However, you suggest to initialize the pipe field with different velocity values, is this correct? If so, how can I do that?

What I have got up to now is a converging but unstable solution: I have bounding epsilon and k warnings, but a convergent solution till time step 295. After that, the max epsilon and k raise suddently and the solution blows away:
I tried to reduce relaxation (till 0.3 on U, epsilon and k and 0.15 on p) and switch to upwind. No way. The weird thing is that the solution looks good at time 295!
Ideas?

maddalena

You could look at the individual cell residuals? That might help you figure out what's causing the instability.

That sounds interesting. How can I do that?

I need to do it myself and am just about to look into it :D

You can jump ahead here:
http://www.cfd-online.com/Forums/ope...residuals.html

Ok, so you need a workmate! I will look into it as well.
Stay in touch.

mad

Done. I modified the simpleFoamResidual utility that hrvoje posted in order to match the new turbulence definition. What I get is a plot showing that the uResidual are higher at the corners of my pipe geometry, thus on the points where the flow is more difficult to model. Does this mean that my mesh is not fine enough on those points?


mad

Same. Popped it up on github:

http://github.com/lrm29/OpenFOAM.loc...dualCalculator

OpenFOAM-1.7.x has some errorEstimation libraries which would be nice to use. The residual that simpleFoamResidual calculates needs to be normalised (by the initial state possibly?) so that the changes from step to step can be seen more clearly.

Were the residuals increasing in those areas? It's difficult to say, there are a number of problems it could be related to. Versteeg and Malalasekera's book has a nice chapter on possible causes of problems.

Another thing that may be worth checking is that the mass flow into and out of your domain matches.

Why my solutiion is not converging?
 

Hello,
still here with the same problem on a different case: pressure & velocity fields look good and their residual's trend is "converging"; however local value of residuals (simpleFoamResidual) does not looks good and I have weird oscillations on the initial residual of every time step.
My mesh (tet mesh with no boundary layer) is nice. I have tried tons of different BC-fvSchemes-fvSolution settings. No way.
May this be due to the high number of cyclic patches I am using? Two fans BC + cyclic sides.
I do not what to think now. Suggestions?

mad

Reversed problem!
 

Ok, maybe this is not the right place where to post, but I hope to get some answer on a problem that is similar to what posted above...
I started this thread speaking of a pressure equation that converges too soon... And I am writing now for a pressure equation that is never solved within the 1000 iterations of a time step! Geometry and bc are similar to what described above, only the pipe geometry is a little bit more complex than what sketched. Check mesh does not complain about that:
.
fvSchemes and fvSolution are:
and this is my weird log.simpleFoam file:
I am using 4 nonOrthogonalCorrectors in order to try to lower p residuals. However, as you can see, pressure equation does not reaches convergence within the 1000 iterations x 4 of each time step. Of course, velocity, turbulence and pressure solution field are far to be as expected.
What I should do? What to change? I really need a help from you!

mad

maddalena

Are you doing some internal loops?

Hello,
fastest answer ever!
No, that is standard simpleFoam, thus no internal loop.

mad

:cool:

could U please post more of your log?

Yes, sure. Here it is.
As you can see, something strange happens around time step 17 on Uz. On the contrary, pressure does what explained above.:confused:

mad

... and your fvScheme and fvSolution in the studio please)))

Written above. However, I tried different combination of them. The log file posted above refers to these two files.

mad

Maybe it is worth adding that my mesh is tetra mainly. I used prisms in proximity of fans, for the reason explained here. Also, the answer I get here is a bit worrying. Any experience on the subject?

mad

First
Second

p
{
solver GAMG;
tolerance 1e-12;
relTol 0; // Not efficient for steady state solution, try ~0.05
smoother GaussSeidel;
nPreSweeps 0;
nPostSweeps 2;
cacheAgglomeration true;
nCellsInCoarsestLevel 10;
agglomerator faceAreaPair;
mergeLevels 1;
}

My thoughts concerned that you are using some pseudo-2nd-order schemes like linearUpwind with limiters, which cause the problems with the convergence. Try to increase velocity tolerance in fvSolution. As from my experience, pressure residuals will improve if you improve velocity field calculation accuracy.

To judge more correctly, try to run first without corrections and limiting with the first order upwind. I have also not really good experience with MDLimited schemes(((

I am currently studying accuracy/convergence issues for different schemes (hope it will result in the paper soon). So far all limiting and improving the order to 2nd and further in convectional schemes bring the problems with convergence.

Also an important comment from Prof. Jasak regarding the need in nonOrtho corrections in your case http://www.cfd-online.com/Forums/ope...tml#post233066

BTW, your solution is not converged to the steady state yet.
Attachment 6377

thank you, however:
corrected is extra, isn't it?
This will no improve the initial convergence, since the solver will stop when the relTol is 0.05. thus it will not run until 1E-12 but stop at 0.05. And pressure equation will be not converged smoothly, I guess. What are your experience on the subject? What do you mean with not efficient?
Somewhere else it has been suggested to use pressure tolerance 2 order of magnitude lower than velocity tolerance. Therefore, as I lower velocity tol, I must lower pressure tol as well. This was suggested as a "remedy" due to the higher difficulty on pressure eq to get convergence.
On the contrary of what reported above, fvSchemes attached on the last post used a linear upwind scheme...
Does it applies with tet mesh or with hea as well?
Hope to get it when published!

Therefore, my next steps are:

1. use relTol 0.05 on p -> BTW, why not efficient?
2. lower U tol
3. use first order everywhere.

One more question: is this setup convergent, but not accurate?

mad

[QUOTE=maddalena;293910]Ok, maybe this is not the right place where to post, but I hope to get some answer on a problem that is similar to what posted above...
I started this thread speaking of a pressure equation that converges too soon... And I am writing now for a pressure equation that is never solved within the 1000 iterations of a time step! Geometry and bc are similar to what described above, only the pipe geometry is a little bit more complex than what sketched. Check mesh does not complain about that:
.
fvSchemes and fvSolution are:
and this is my weird log.simpleFoam file:
I am using 4 nonOrthogonalCorrectors in order to try to lower p residuals. However, as you can see, pressure equation does not reaches convergence within the 1000 iterations x 4 of each time step. Of course, velocity, turbulence and pressure solution field are far to be as expected.
What I should do? What to change? I really need a help from you!

mad[/QUOTE

1) Why a so severe convergence criterion whithin the single time step? I have a bit of experience with simpleFoam on tetra/prisms meshes and In my runs I do prefer to set a relative convergence criterion of 10^-05 for the pressure and of 10^-03 for the other quantities: meanly speaking, this should be far enough to reach a satisfactory final convergence

2) Why only 10 cells in coarsest level for the GAMG solver? How big is your mesh? I'm not a matrix-solver expert, but I've read somewhere here in the forum that the number of cells in coarsest level should be roughly equal to the root squared of the number of cells in the domain (and this setting has found to be appropriate for my runs as well)

3) What kind of k-epsilon model are you using? To my experience, looking at the linear High-Re models implemented in OpenFOAM, the standard k-epsilon is the most stable, then comes the realizable k-epsilon and finally the RNG, which is less dissipative than the others and thus more difficult to lead to convergence

4) Why limiting both the velocity and pressure gradients? The pressure gradient is used at each iteration loop inside the pressure-velocity correction procedure, thus imposing a limiter upon it could maybe improve numerical convergence, but also lead to unphysical results (this is what indeed has happened in my runs)

5) Finally, try to set Gauss linearUpwindV cellMDLimited Gauss linear 1 only for div(phi,U), and simply Gauss upwind for the other convective terms: in my runs, when I use the realizable k-epsilon model with standard wall functions, setting a higher order interpolation scheme for the turbulent quantities too does not have a significant influence on the accuracy of the results.

Best Regards

V.

Yes, I know! That is exactly the point!

Hello V, and thank you to join the discussion
This has been suggested here
Good to know. I will set up it properly.
Launder-Sharma KE + Low Re wall function.
I wanted to improve the numerical convergence...
Ok, I recall only now your suggestion...

Let us keep in touch.

mad

You are running steady state, there is no point in converging all your equation to the absolute tolerance value, you will reach it with the steady state. Thus 0.05 for p and 0.1 for U (with the smoothSolver instead of CG) is a good decision.

Did you reach the state, when all you residuals (apart from pressure) become flat?

and
Mmm... these are on the opposite direction of what suggested by Alberto here.

Never reached it... :o Simulation crashed before I could get to it.

You are wellcome ;)


I think that there are some issues about the tolerances that have to be clarified: lowering a lot the absolute convergence criterion assures that if eventually the residual of one of the variables for which you are solving falls down to a much lower value then the others (in OF this happens, for instance, with the omega in the k-omega turbulence model), the code will keep to solve for every variable, thus avoiding the "danger" of an only partially resolved global problem. However, it is also my opinion (I know that other CFD users and developers have different ideas about it) that forcing the solver to push down the residuals under exremely low values at every time step is not so useful as it seems to be (especially if combined with under-relaxed solution practices, such as the SIMPLE one): therefore, I do prefer to set the absolute tolerances to very low values (10^-11/10^-12), but also to keep control over the relative convergence criterion (as I wrote in my previous post), and till now this kind of practice has found to be quite effective for my cases...

Good luck with your run

V.

PS-Improving numerical convergence is meaningful only if you reach satisfactory physical behavior of your system: if not so, it simply becomes a mathematical exercise...

That is the best explanation I have had on the subject up to now.
I will try to put it in practice and report my (hopefully good) results.

mad

My question regarding convergence and residuals here:
why some time k-epsilon equation stop being solved with Tol 10^-5???
Velocity and pressure have settings for the tolerance of order, let's say, 10^-5 and 10^-8 accordingly at the same time. Thus k-epsilon fields seem to be frozen when observing the results. If tolerance is set to 10^-14, then k-epsilon pattern dramatically changes and "looks" more physically.

Dear Maddalena,

convergence issues are always really frustrating ! My post probably is not a real help, just an attempt to turn on some different lights.

Residuals on pressure seems reduced of 7 order of magnitude after 1000 iterations. Did you try to reduce the number of max iterations to see how much residuals are diminished after, to say, 300 iterations ? If you get the same order of magnitude, this could indicate that the solver has been trapped into a false solution.

Maybe you can try to solve on a coarser grid, than interpolate the coarse solution onto you final grid.

Another attempt could be to adopt a transient solver, to see where the solution blows up (if this happens again) and try to identify the critical issue.

I am sorry I do not have a real solution.

Regards,

Franco

coarse levels cells as 10 is fine.

I will explain this issue. OpenFOAM uses additive corrective multigrid. In this coarse level is generated by merging two cells at a time and creating one cell from it. Since it is algebraic multigrid there are no physical cells to be generated just that two equations would merge and become 1.
So if you started with say N equations the next coarse level ideally should have N/2 cells. I said ideally because some cells escape this aggolomoration process and hence they are merged with their neighbours who are part of coarse level. So some coarse equations may consist of say 3 or 4 or more equations.

So the multigrid levels would fall like this:
N , N/2 , N/4, N/8 ....

The the parameter coarset level that you set it to 10 says that below this number of equations direct solver will be used to solve. (instead of iterative solver like other levels).
Because of this reason this number should be small enough to be efficiently solved by direct method. Imagine if this direct method is of order O(N^3) then you may be in problem if you chose this parameter large.

Take for example if you mesh has 1 million cells then sqrt(1000000) = 1000.
so if you set this then your will have to wait a lot for direct solver to finish. It will all kill the efficiency of your solver.

usually this parameter is set to 50 to 100. I personally use it as 1 in my multigrid solver. (but that is different multigrid).

Hi Franco, and thanks for your comment. How can I set the max iteration number? Is there a missing parameter on my fvSolution where can I set it?
Wow, detailed answer on the subject, thanks.
V, can you please comment on that? Can you share your experience on the subject?

Any other comment on the subject? This thread is becoming really interesting...

mad

Hello, everybody,



this is exactly the same experience I've made with my simpleFoam simulations. My best practice usually is setting tolerance for every quantity to 1e-9 or lower and relTol to 0.1. The quite low tolerance values ensure the governing equations being solved during the whole simulation process (avoiding e.g. p not being solved for anymore) and the big relative tolerances reduce the number of inner iterations for each quantity, thus (usually) avoiding >1000 iterations per outer iteration.

This usually works like a charm for me. I manually check for convergence and stop the simulation when all the initial residuals have fallen below a certain tolerance (1e-4, for example). In the next version of OF this can be automatically accomplished by using the new residualControl function.

Just remember: the low tolerance value isn't imposed for accuracy, but to make sure that the equations keep being solved. OF handles residual control a bit differently than e.g. FLUENT.


Another thing: have you tried a different solver for p than GAMG? I recently made the experience that PCG can be a lot faster than GAMG for certain cases. Which may sound a bit weird for all the benefits multigrid methods have, but it's just my experience. Give it a shot, if you haven't already!


Greetings,
Felix.

As I said in the previous post, my knowledge about the GAMG (and, in general, the algebraic solvers employed for CFD problems) is far from being exhaustive...I found here in the forum a post (unfortunately I don't remember the name of the discussion) where a kind of criterion for the choice of the number of cells in coarsest level was suggested (the square root of the number of cells in the domain) and then I've tried it for my runs: with domains of a few milions of cells (1.5 up to 5 milions) I can tell you that passing from 1000 to 50 cells does not have any effect on the solver efficiency, but this doesn't prove that such a criterion is universally correct or not (probably the differences in efficiency will come out in smaller domains, where the solver will reach faster the coarsest level and then start to solve dicrectly, as said in the comment posted above). However, all of this is to remark that, differently from what I said concerning the tolerances and the SIMPLE procedure, about GAMG I can talk only by personal experience and therefore for your case the solver's behavior could be different.

V.

Hi Felix,
I've tried both PCG and GAMG as solvers for p, but my experience goes in a different direction than yours...In particular, if the relTol parameter for p starts to be quite low (I usually use something like 10^-04/10^-05) the GAMG solver is much faster than the PCG one. Can you explain for which cases you have found an opposite behavior?
Thanks

V.

Ok, that is fine. Seen from a different point of view, this says that using a lower cell number will prevent me to make a long simulation without significant improvement on results.
That is interesting for me as well.


there is a simulation running with the setup suggested above. Hope in some hours I can get a decent result from it.
stay tuned.

mad

PS: btw, you adopted V as your official signature? ;) that sounds good!

Yes, that's my understanding too


I simply like informal signatures...;)