CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

pressure eq. "converges" after few time steps

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree14Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   February 9, 2011, 07:41
Default
  #61
Senior Member
 
Dr. Alexander Vakhrushev
Join Date: Mar 2009
Posts: 213
Rep Power: 10
makaveli_lcf is on a distinguished road
Send a message via ICQ to makaveli_lcf
So, results for
1. Uncorrected
2. Limited 0.333
3. Limited 0.5
4. Limited 0.667
5. Corrected

Uncorrected.pngLimited_0.333.pngLimited_0.5.pngLimited_0.667.pngCorrected.png

!!! Stair type of the plot is used to distinguish iteration values better, not the numerical behavior !!!
fumiya likes this.
__________________
Best regards,

Dr. Alexander VAKHRUSHEV

Christian Doppler Laboratory for "Advanced Process Simulation of
Solidification and Melting"

Simulation and Modelling of Metallurgical Processes
Department of Metallurgy
University of Leoben

Franz-Josef-Str. 18
A - 8700 Leoben
Österreich / Austria
Tel.: +43 3842 - 402 - 3125
http://smmp.unileoben.ac.at

Last edited by makaveli_lcf; February 9, 2011 at 08:00.
makaveli_lcf is offline   Reply With Quote

Old   February 18, 2011, 09:23
Default
  #62
Senior Member
 
Dr. Alexander Vakhrushev
Join Date: Mar 2009
Posts: 213
Rep Power: 10
makaveli_lcf is on a distinguished road
Send a message via ICQ to makaveli_lcf
Another issue that I found:
I plotted the pressure residuals for my pimpleFoam solution (see Fig).
p_resid_relax_p=0.3_U=0.7.png

schemes are
gradSchemes: cellLimited leastSquares 1;
div: upwind
laplacian and surface gradients: Gauss linear limited 0.5; limited 0.5;

Initial under-relaxation parameters:
Code:
p    0.3;
U    0.7;
As you see from the first plot, residuals go down pretty well with the outer corrections, but at the end of the loop (here relaxation for the pressure and the momentum equation matrix are canceled according to OF's PIMPLE algorithm to get the most precise and expensive solution only at the last iteration) pressure residual jump almost to the initial value!!!
I fought with it varying under-relaxation parameters, increasing the step number of the corrections (outer-, neighbor- and non-orthogonality) ; changed the used schemes to fully corrected and removed cell limiting; reduced Courant number to < 1....
Nothing from those helped!

Sudden solution was to REMOVE THE UNDER-RELAXATION OF THE MOMENTUM EQUATION !
p_residual_fixed.png
Why is it so, I have now explanation! The whole advantage of the under-relaxation is vanished!

For the clarification, final working settings, which removed residuals jump are:
Code:
relaxationFactors
{
    p    0.2...0.8;  //  For higher values solution diverges (Co ~ 4)
    U    1;
}
Here I would really appreciate your comments on the following topics:

a) As I understood, in FLUENT relaxation is applied only for the fields (please correct me if I am wrong!).
Here in OF's PIMPLE as well as in PISO and SIMPLE algorithms, it is "field under-relaxation" being applied for the pressure versus "matrix under-relaxation" for the momentum equation to increase its diagonal dominance. In presented case according to my observations momentum under-relaxation makes no sense....

b) Is there any way to get initial residuals not solving the linear system in OF? As far as I know, Solver Performance Class returns required information regarding residuals only by means of the "solve" method... Setting maxIter parameter to 0 for the linear solver does not help!
BTW, Franco, thanks a lot for indicating this solver parameter, it is rather useful!)))

Regards to all... And may the Source be with you!)))

Alexander
fumiya likes this.
__________________
Best regards,

Dr. Alexander VAKHRUSHEV

Christian Doppler Laboratory for "Advanced Process Simulation of
Solidification and Melting"

Simulation and Modelling of Metallurgical Processes
Department of Metallurgy
University of Leoben

Franz-Josef-Str. 18
A - 8700 Leoben
Österreich / Austria
Tel.: +43 3842 - 402 - 3125
http://smmp.unileoben.ac.at
makaveli_lcf is offline   Reply With Quote

Old   March 8, 2011, 06:24
Default
  #63
Member
 
Vishal Jambhekar
Join Date: Mar 2009
Location: University Stuttgart, Stuttgart Germany
Posts: 90
Blog Entries: 1
Rep Power: 8
vishal is on a distinguished road
Hi All,

I am also trying to do flow simulation for a city model. And using Simplefoam form the same. I am also facing similer kind of issues as MALLALENA

please rever to following post for case details.

http://http://www.cfd-online.com/For...urbulence.html

I was thinking it is due to inlet conditions but I found out that the pressure solwing is getting blown up after few iterations.

I am using tetrahedral mesh.

Thanks a lot for ur kind help
__________________
Cheers,

Vishal Jambhekar...
"Simulate the way ahead......!!!"
vishal is offline   Reply With Quote

Old   March 8, 2011, 06:30
Default
  #64
Member
 
Vishal Jambhekar
Join Date: Mar 2009
Location: University Stuttgart, Stuttgart Germany
Posts: 90
Blog Entries: 1
Rep Power: 8
vishal is on a distinguished road
Hi All,

I am also trying to do flow simulation for a city model. And using Simplefoam form the same. I am also facing similer kind of issues as MALLALENA

please rever to following post for case details.

http://http://www.cfd-online.com/For...urbulence.html

I was thinking it is due to inlet conditions but I found out that the pressure solwing is getting blown up after few iterations.

I am using tetrahedral mesh.

Thanks a lot for ur kind help
__________________
Cheers,

Vishal Jambhekar...
"Simulate the way ahead......!!!"
vishal is offline   Reply With Quote

Old   March 8, 2011, 11:32
Default
  #65
Member
 
Vishal Jambhekar
Join Date: Mar 2009
Location: University Stuttgart, Stuttgart Germany
Posts: 90
Blog Entries: 1
Rep Power: 8
vishal is on a distinguished road
Quote:
Originally Posted by maddalena View Post
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:
Code:
Time = 295

DILUPBiCG:  Solving for Ux, Initial residual = 0.11505, Final residual = 8.32225e-11, No Iterations 13
DILUPBiCG:  Solving for Uy, Initial residual = 0.934182, Final residual = 7.36365e-11, No Iterations 14
DILUPBiCG:  Solving for Uz, Initial residual = 0.713126, Final residual = 4.13259e-11, No Iterations 13
GAMG:  Solving for p, Initial residual = 1.86515e-09, Final residual = 9.94925e-13, No Iterations 206
GAMG:  Solving for p, Initial residual = 6.88289e-10, Final residual = 7.66889e-13, No Iterations 9
time step continuity errors : sum local = 4.67002e-09, global = 1.51568e-10, cumulative = -2.05894e-08
smoothSolver:  Solving for epsilon, Initial residual = 0.00158922, Final residual = 7.46827e-11, No Iterations 24
bounding epsilon, min: 1.30954e-18 max: 5812.76 average: 93.9024
smoothSolver:  Solving for k, Initial residual = 7.82377e-09, Final residual = 4.92151e-11, No Iterations 5
bounding k, min: 6.82659e-17 max: 14.436 average: 0.424139
ExecutionTime = 65389.8 s  ClockTime = 65515 s

Time = 296

DILUPBiCG:  Solving for Ux, Initial residual = 0.328206, Final residual = 5.57292e-11, No Iterations 33
DILUPBiCG:  Solving for Uy, Initial residual = 0.904646, Final residual = 3.81614e-11, No Iterations 30
DILUPBiCG:  Solving for Uz, Initial residual = 0.678265, Final residual = 3.27509e-11, No Iterations 29
GAMG:  Solving for p, Initial residual = 0.000198723, Final residual = 9.87374e-13, No Iterations 723
GAMG:  Solving for p, Initial residual = 5.88726e-07, Final residual = 9.89924e-13, No Iterations 273
time step continuity errors : sum local = 2.72317e-07, global = -1.44975e-09, cumulative = -2.20392e-08
smoothSolver:  Solving for epsilon, Initial residual = 0.998411, Final residual = 5.92556e-11, No Iterations 35
bounding epsilon, min: 1.30845e-18 max: 7.92429e+07 average: 1496.69
smoothSolver:  Solving for k, Initial residual = 1.39098e-07, Final residual = 5.71729e-11, No Iterations 5
bounding k, min: -2.01645e-14 max: 449863 average: 2.44943
ExecutionTime = 65807.2 s  ClockTime = 65932 s

Time = 297

DILUPBiCG:  Solving for Ux, Initial residual = 0.693738, Final residual = 2.49235e-11, No Iterations 28
DILUPBiCG:  Solving for Uy, Initial residual = 0.745261, Final residual = 2.71405e-11, No Iterations 28
DILUPBiCG:  Solving for Uz, Initial residual = 0.715263, Final residual = 2.6154e-11, No Iterations 28
GAMG:  Solving for p, Initial residual = 1.06952e-05, Final residual = 9.67823e-13, No Iterations 738
GAMG:  Solving for p, Initial residual = 3.03894e-09, Final residual = 9.87472e-13, No Iterations 31
time step continuity errors : sum local = 0.00097431, global = 7.21803e-06, cumulative = 7.196e-06
smoothSolver:  Solving for epsilon, Initial residual = 0.587168, Final residual = 7.92945e-11, No Iterations 18
bounding epsilon, min: 1.56953e-17 max: 9.66762e+12 average: 6.49312e+07
smoothSolver:  Solving for k, Initial residual = 0.00708516, Final residual = 1.51465e-11, No Iterations 11
bounding k, min: -3.00985e-15 max: 3.33247e+10 average: 154254
ExecutionTime = 66136 s  ClockTime = 66261 s

Time = 298

DILUPBiCG:  Solving for Ux, Initial residual = 0.652017, Final residual = 5.22231e-11, No Iterations 23
DILUPBiCG:  Solving for Uy, Initial residual = 0.523133, Final residual = 6.68451e-11, No Iterations 21
DILUPBiCG:  Solving for Uz, Initial residual = 0.677302, Final residual = 8.86501e-11, No Iterations 22
GAMG:  Solving for p, Initial residual = 4.62234e-08, Final residual = 9.77244e-13, No Iterations 566
GAMG:  Solving for p, Initial residual = 2.08294e-10, Final residual = 7.37324e-13, No Iterations 4
time step continuity errors : sum local = 0.0110342, global = 0.000335115, cumulative = 0.000342311
smoothSolver:  Solving for epsilon, Initial residual = 0.00963571, Final residual = 9.99631e-11, No Iterations 26
bounding epsilon, min: -2.55095e-15 max: 2.70603e+18 average: 2.26696e+13
smoothSolver:  Solving for k, Initial residual = 0.00019889, Final residual = 6.88818e-11, No Iterations 21
bounding k, min: -2.62403e-13 max: 6.83816e+11 average: 6.84336e+06
ExecutionTime = 66386.5 s  ClockTime = 66512 s
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
Hi Maddalena,

Similar situation is happening for me. The solution blows up after some time steps. I also have bonding values for K and epsilon. Can you please tell me what did you do to make solution stable. I have also reduced relaxation factor an reltol (0.05) but still not working.

Please let me know...
__________________
Cheers,

Vishal Jambhekar...
"Simulate the way ahead......!!!"
vishal is offline   Reply With Quote

Old   March 10, 2011, 03:36
Default
  #66
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hello,
what does this mean?
Quote:
Originally Posted by vishal View Post
The solution blows up after some time steps. I also have bonding values for K and epsilon.
Some time step means after less than 50 time step or after a while? The first cause of solution instability is BC assigned badly. If your solution blows up within 50 iterations, than this is probably the cause.
Otherwise, you may have bad cells (what checkmesh says?) or schemes which are not good, thus you have to play a bit with them.
In any case:
  1. this is not the topic of this discussion. Please open your own thread and you will get specific answer.
  2. it is not a good idea to post the same reply in more copy and in more threads.
The next time, pleast take care of these simple rules!

mad
maddalena is offline   Reply With Quote

Old   March 10, 2011, 05:13
Default
  #67
Member
 
Vishal Jambhekar
Join Date: Mar 2009
Location: University Stuttgart, Stuttgart Germany
Posts: 90
Blog Entries: 1
Rep Power: 8
vishal is on a distinguished road
Hi Maddalena,

My apologies for inconvinience. Can you please help me a bit. I think you have already figured out the way for stable solution. my case details are posted here.

Help with k epsilon values of turbulence

I have also attached check mesh log in the same thread.

Thanks a lot for ypur help

VJ
__________________
Cheers,

Vishal Jambhekar...
"Simulate the way ahead......!!!"
vishal is offline   Reply With Quote

Old   July 21, 2011, 06:49
Default
  #68
New Member
 
Joel Lehikoinen
Join Date: Jun 2011
Posts: 26
Rep Power: 6
joel.lehikoinen is on a distinguished road
This is an old topic, but I think it is still of interest to many, so I'll post my findings on the subject here. I had some trouble getting a buoyantPimpleFoam test case to converge, but in the end, I think I managed to get it to converge nicely. I will first describe the case in detail, and then outline the steps I took to improve convergence and accuracy.

I was simulating a simple case of pipe flow in a circular pipe with mesh of just 80000 cells. The solver used here is buoyantPimpleFoam. The flowing fluid is water, initially at temperature of 10 C. I used the icoPoly8 thermodynamics package, with coefficients obtained by fitting a curve to thermophysical property data from NIST webbook. Diameter of the pipe is 140 mm and its length is 1070 mm. The flow velocity at inlet is 0.5 m/s in the positive x-axis direction. The flow is turbulent (Re 10600), and the turbulence model used was the standard k-epsilon. The boundary conditions were set followingly:

U:
Code:
Inlet: fixed velocity at 0.5 m/s
Outlet: pressureInletOutletVelocity
Wall: fixed 0 m/s (no-slip)
p_rgh:
Code:
Inlet: buoyantPressure
Outlet: fixed 10000 Pa
Wall: zeroGradient
T:
Code:
Inlet: fixed 283 K
Outlet: zeroGradient
Wall: fixed 350 K
The turbulence quantities had wall functions on the walls and turbulentIntensityKineticEnergyInlet (I=20%) or compressible::turbulentMixingLengthDissipationRate Inlet at the inlet. Timestep was 0.2 s, and courant number max and mean, around 0.5.

Attached you will find my fvSolution and fvSchemes files, as well as a plot of initial residuals vs. time. I made some changes during runTime to these files, which can be seen in the plot. First I played around a bit with the underrelaxation coefficients, but unfortunately I didn't document what I did exactly.
  • At time t=1.0 s, I changed the ddtScheme from Euler to CrankNicholson 0.5. This offered a better convergence than CrankNicholson 1 and better accuracy than Euler.
  • At time t=1.32 s, I reduced maxIter of p_rghFinal to 50. I had been reducing it gradually from the default value of 1000. The effect on accuracy was small, less than a decade (final residual was usually between 1e-9 and 1e-10). This made the calculation somewhat faster.
  • At time t=1.52 s I increased the pressure underrelaxation coefficient from 0.6 to 0.8 (I'm assuming here p also works for p_rgh). I also changed the divScheme from Gauss linear corrected to Gauss cubic. This improved accuracy and rate of convergence clearly. I tried to change the gradScheme to fourth, but that didn't give good results, the residuals settled to a level above that of Gauss linear.
  • At about t=3.7 s, the pressure solver started to have trouble meeting the relTol criteria, and the number of iterations shot up to 1000 (maximum). Time step solving time increased to almost 9-fold. However, I found that I could reduce the number of maxIter to 150, without a notable loss of accuracy. This brought the solving time down to one quarter of the large value.
I know this is not a real systematic study, and probably my solvers, schemes and their settings are not optimal. I am a beginner at CFD, and only lately I have had to delve into the stability-convergence-accuracy love triangle. But I hope these findings are of help to other FOAMers; at least I've found this thread very interesting and helpful. I will post my future findings and experiences here, too.

In conlusion, at least for the case in question we found out that:
  1. CrankNicholson 0.5 was stabler than CrankNicholson 1 and more accurate than Euler.
  2. Reducing the number of maxIter (for the pressure solvers) can speed up the simulation considerably. One must keep an eye for the accuracy though!
  3. Gauss cubic divScheme gives superior accuracy and rate of convergence compared Gauss linear corrected. However, at least in some cases it might be better to start with Gauss linear corrected as in my experience it's more stable.
  4. Changing gradScheme to fourth resulted in larger residuals.
Attached Images
File Type: jpg residuals.jpg (35.1 KB, 99 views)
Attached Files
File Type: txt fvSolution.txt (2.1 KB, 70 views)
File Type: txt fvSchemes.txt (2.0 KB, 74 views)
Amir likes this.
joel.lehikoinen is offline   Reply With Quote

Old   July 21, 2011, 07:29
Default
  #69
Senior Member
 
Felix L.
Join Date: Feb 2010
Location: Hamburg
Posts: 165
Rep Power: 9
FelixL is on a distinguished road
Quote:
Originally Posted by joel.lehikoinen View Post
stability-convergence-accuracy love triangle
That one cracked me up, love it!

Thanks for sharing your findings, keep posting. It's interesting to see how other solvers behave in regards of convergence.
FelixL is offline   Reply With Quote

Old   July 21, 2011, 07:42
Thumbs up
  #70
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Quote:
Originally Posted by joel.lehikoinen View Post
I hope these findings are of help to other FOAMers; at least I've found this thread very interesting and helpful. I will post my future findings and experiences here, too.
that is the right way of doing things in OpenFOAM: sharing experience! thank you to have joined in this thread!
maddalena is offline   Reply With Quote

Reply

Tags
convergence issues, pipe flow, simplefoam

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
TimeVaryingMappedFixedValue irishdave OpenFOAM Running, Solving & CFD 28 May 28, 2015 13:37
time Step's turbFoam >>> exit mgolbs OpenFOAM Pre-Processing 4 December 8, 2009 04:48
Modeling in micron scale using icoFoam m9819348 OpenFOAM Running, Solving & CFD 7 October 27, 2007 00:36
Hydrostatic pressure in 2-phase flow modeling (CFX4.2) HB &DS CFX 0 January 9, 2000 14:19
unsteady calcs in FLUENT Sanjay Padhiar Main CFD Forum 1 March 31, 1999 12:32


All times are GMT -4. The time now is 17:24.