# Second Order in rhoSimpleFoam

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

 August 27, 2014, 07:14 Second Order in rhoSimpleFoam #1 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Hello everyone, I am coming back after fixing the problem I used to have here : http://www.cfd-online.com/Forums/ope...ation-2-a.html Now my simulation converges well with first order schemes. The thing is that now, I would like to use Second Order schemes (linear or QUICK) in the divergence schemes to increase the model's precision. I use the result of the first order simulation as initial condition for the second order but it crashes sooner or later with the use of such schemes. Pressure and velocity explode and reach unrealistic values. Is there anything doable to avoid this numerical behaviour ? Thanks in advance for your help, Seb PS: this problem is referenced in the following thread as well and nobody answered http://www.cfd-online.com/Forums/ope...r-schemes.html

 September 1, 2014, 08:23 #2 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Still nobody ? Seb

September 2, 2014, 03:37
#3
Member

Laurent Fitschy
Join Date: May 2011
Posts: 40
Rep Power: 8
Hi,

If your Mach number is above 0.75 in some places, I suggest you to activate transonic flag in fvSolution :

Quote:
 SIMPLE { transonic true; . . . }
From my experience, you need a really good mesh (essentially hex) to be able to use second order schemes with rhoSimpleFoam and high Mach number.

Good luck.

 September 2, 2014, 04:03 #4 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Hello Thanks for the tip. The thing is when I use "transonic true;", rhoSimpleFoam rises : Code: ```Starting time loop Time = 3001 smoothSolver: Solving for Ux, Initial residual = 2.32034e-06, Final residual = 1.84847e-08, No Iterations 2 smoothSolver: Solving for Uy, Initial residual = 0.00324492, Final residual = 2.34545e-05, No Iterations 2 smoothSolver: Solving for Uz, Initial residual = 0.000158151, Final residual = 1.15094e-06, No Iterations 2 DILUPBiCG: Solving for e, Initial residual = 2.32848e-05, Final residual = 3.35775e-07, No Iterations 1 --> FOAM FATAL IO ERROR: Unknown asymmetric matrix smoother DICGaussSeidel Valid asymmetric matrix smoothers are : 5 ( DILU DILUGaussSeidel GaussSeidel nonBlockingGaussSeidel symGaussSeidel ) file: /scratch/*****.rep/system/fvSolution.solvers.p from line 22 to line 29. From function lduMatrix::smoother::New in file matrices/lduMatrix/lduMatrix/lduMatrixSmoother.C at line 126. FOAM exiting``` I've never experienced such an error. Do you know what might be going on here ?

 September 2, 2014, 04:26 #5 Member   Laurent Fitschy Join Date: May 2011 Posts: 40 Rep Power: 8 yes, pressure equation is different now and you have to use an asymmetric smoother. Replace DICGaussSeidel by DILUGaussSeidel for pressure equation in fvSolution.

 September 3, 2014, 03:36 #6 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Hello Laurent, I followed your advice and until now, the solver seems to run. But it takes a incredibly long time to go through "p" equation, iterating it 1000 times for every new iteration. Plus, the residuals seem to oscillate a lot. I tried lowering the tolerances for "p" solver in the fvSolution dictionnary but sooner or later these 1000 iterations end up coming back. Do you have an idea of what is happening here ? Thanks for your help Seb

 September 3, 2014, 03:55 #7 Member   Laurent Fitschy Join Date: May 2011 Posts: 40 Rep Power: 8 Hi Seb, p equation going to the maximum default number of iterations (1000) without convergence means that something is wrong in your setup (i.e. boundary conditions or mesh). Residual oscillations is another story and probably comes from the unsteadiness in your flow or pressure wave reflections. Maybe I would be able to help you more if you post some pictures of your mesh and flow field. Regards.

 September 4, 2014, 06:12 #8 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Hi Laurent, Here are the pictures you asked for. Here is the result of checkMesh: Code: ```Checking geometry... Overall domain bounding box (-5.16 -5.16 -5.16) (5.16 5.16 5.16) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty) directions (1 1 1) Boundary openness (-2.76836e-18 4.16889e-17 -1.94542e-17) OK. Max cell openness = 5.28473e-15 OK. Max aspect ratio = 106.421 OK. Minimum face area = 1.69335e-09. Maximum face area = 4.26113. Face area magnitudes OK. Min volume = 2.9706e-12. Max volume = 8.79548. Total volume = 1099.1. Cell volumes OK. Mesh non-orthogonality Max: 73.5736 average: 9.737 *Number of severely non-orthogonal faces: 160. Non-orthogonality check OK. <

 September 4, 2014, 08:41 #9 Member   Laurent Fitschy Join Date: May 2011 Posts: 40 Rep Power: 8 Hi, your settings seem to be ok. Be sure your freestream boundaries are far away from your object (at least 20x object size). You should refine your mesh in the wake since size transition occurs too close to the object. If it does not solve your problem, try with more relaxation. Good luck !

 September 4, 2014, 09:47 #10 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Okay, so, I refined the wake a little more, and the boundaries are far enough (more than 20 times the object length). Unfortunately, the second order schemes still doesn't manage to converge I use to do : All upwind and first order schemes with low relaxation factors (0.1, sometimes lower) for the first 500 iterations. Then I rise the relaxation factors (up to 0.5 - 0.6, step by step if necessary) for the 500 or more next iterations. Then I finally switch to 2nd order schemes (linear/QUICK/linearUpwind for fivSchemes) with lower relaxation factor (0.01) and run for 1000 iterations at least. But even at this point, the solver crashes ... Is there something I'm doing wrong in this method ? Should I use a coarser mesh first ? Should I lower the relaxation factors even more ? I'm running out of solutions ^^ Plus, I feel like the output Aerodynamic Coefficients don't seem right. With positive incidence, I get a negative lift coefficient and wrong values in general. Doesn't sound right to me... Might it be related with the convergence problem ? Here is how I call them: Code: ```functions { coefficientsAero { // type forces; type forceCoeffs; functionObjectLibs ("libforces.so"); // outputControl outputTime; outputControl timeStep; log yes; patches ( "geometrie_.*" ); // I have many patches rhoInf 1.17659 ; CofR ( 0 0 0 ); lRef 0.037 ; Aref 0.0010752 ; dragDir ( 1 0 0 ) ; liftDir ( 0 0 1 ) ; pitchAxis ( 0 1 0 ) ; magUInf 173.612 ; } }``` PS: even with first order schemes where I reach a good convergence, the coefficient appear to be this way and they do not evolve to physically correct values (i.e. positive lift) If you have any clue about this, I'm interested ! Thanks again for your help and patience Seb

 September 4, 2014, 10:04 #11 Member   Laurent Fitschy Join Date: May 2011 Posts: 40 Rep Power: 8 when I can't make rhoSimpleFoam running fine, I switch to sonicFoam ! sonicFoam is often slower (unstready solver -> limited by courant number) but it is really more stable than rhoSimpleFoam for transonic flows.

 September 9, 2014, 04:01 #12 New Member   Bonjour Join Date: Jul 2014 Location: France Posts: 23 Rep Power: 5 Hello Laurent, Thanks for your help again, I'll see what I can do with this Seb

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Many OpenFOAM Running, Solving & CFD 0 February 25, 2014 07:58 NormalVector FLUENT 3 April 3, 2013 15:43 Far Main CFD Forum 7 March 14, 2013 13:29 ken FLUENT 8 March 14, 2013 04:43 Torque_Converter CFX 7 January 8, 2013 05:07

All times are GMT -4. The time now is 14:45.