First
Code:
div((nuEff*dev(grad(U).T()))) Gauss linear corrected; // Mistyped 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
|
1 Attachment(s)
BTW, your solution is not converged to the steady state yet.
Attachment 6377 |
thank you, however:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Therefore, my next steps are:
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: Code:
Overall domain bounding box (-37.4532 -6.70564 -3.99289e-17) (42.605 6.70578 27.2094) fvSchemes and fvSolution are: Code:
grad faceMDLimited Gauss linear 0.5; Code:
p Code:
DILUPBiCG: Solving for Ux, Initial residual = 0.0028965, Final residual = 2.16561e-11, No Iterations 7 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. |
Quote:
|
Hello V, and thank you to join the discussion
Quote:
Quote:
Quote:
Quote:
Quote:
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? |
Quote:
Quote:
Quote:
|
Quote:
Quote:
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... |
Quote:
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 |
Quote:
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). |
Quote:
Quote:
Quote:
Any other comment on the subject? This thread is becoming really interesting... mad |
Hello, everybody,
Quote:
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. |
Quote:
V. |
Quote:
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. |
Quote:
Quote:
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! |
Quote:
Quote:
|
All times are GMT -4. The time now is 07:15. |