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

Second Order in rhoSimpleFoam

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

Reply
 
LinkBack Thread Tools Display Modes
Old   August 27, 2014, 07:14
Default Second Order in rhoSimpleFoam
  #1
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
Hello everyone,

I am coming back after fixing the problem I used to have here : rhoSimpleFoam: solver error, iteration 2

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

rhoSimpleFoam blows up with second order schemes
seb_210 is offline   Reply With Quote

Old   September 1, 2014, 08:23
Default
  #2
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
Still nobody ?

Seb
seb_210 is offline   Reply With Quote

Old   September 2, 2014, 03:37
Default
  #3
Member
 
Laurent Fitschy
Join Date: May 2011
Posts: 39
Rep Power: 6
GDTech is on a distinguished road
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.
GDTech is offline   Reply With Quote

Old   September 2, 2014, 04:03
Default
  #4
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
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 ?
seb_210 is offline   Reply With Quote

Old   September 2, 2014, 04:26
Default
  #5
Member
 
Laurent Fitschy
Join Date: May 2011
Posts: 39
Rep Power: 6
GDTech is on a distinguished road
yes, pressure equation is different now and you have to use an asymmetric smoother.
Replace DICGaussSeidel by DILUGaussSeidel for pressure equation in fvSolution.
GDTech is offline   Reply With Quote

Old   September 3, 2014, 03:36
Default
  #6
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
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
seb_210 is offline   Reply With Quote

Old   September 3, 2014, 03:55
Default
  #7
Member
 
Laurent Fitschy
Join Date: May 2011
Posts: 39
Rep Power: 6
GDTech is on a distinguished road
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.
GDTech is offline   Reply With Quote

Old   September 4, 2014, 06:12
Default
  #8
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
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.
  <<Writing 160 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 3.27693 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End
Concerning the boundary/initial conditions, here is what I have for Spalart-Allmaras model:

- p field
Code:
internalField uniform 1.01325e+05

boundaryField
domain limits: freeStreamPressure
object surface: zeroGradient
- U field
Code:
internalField uniform ( 172 0 15) // Mach0.5, incidence 5

boundaryField
domain limits: freestream
freestreamValue uniform ( 172 0 15)
object surface: fixedValue
value uniform (0 0 0) // no slip
- nuTilda field:

Code:
internalField uniform 0.001 

boundaryField
domain limits: freestream
freestreamValue $internalField
object surface: fixedValue
value uniform 0
- mut field:
Code:
internalField uniform 0

boundaryField
domain limits: calculated
value $internalField
object surface: mutUWallFunction
value $internalField
Any ideas ?

Thanks a lot

Seb

Last edited by seb_210; September 8, 2014 at 11:03.
seb_210 is offline   Reply With Quote

Old   September 4, 2014, 08:41
Default
  #9
Member
 
Laurent Fitschy
Join Date: May 2011
Posts: 39
Rep Power: 6
GDTech is on a distinguished road
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 !
GDTech is offline   Reply With Quote

Old   September 4, 2014, 09:47
Default
  #10
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
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
seb_210 is offline   Reply With Quote

Old   September 4, 2014, 10:04
Default
  #11
Member
 
Laurent Fitschy
Join Date: May 2011
Posts: 39
Rep Power: 6
GDTech is on a distinguished road
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.
GDTech is offline   Reply With Quote

Old   September 9, 2014, 04:01
Default
  #12
New Member
 
Bonjour
Join Date: Jul 2014
Location: France
Posts: 23
Rep Power: 3
seb_210 is on a distinguished road
Hello Laurent,

Thanks for your help again, I'll see what I can do with this

Seb
seb_210 is offline   Reply With Quote

Reply

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
rhoSimpleFoam blows up with second order schemes Many OpenFOAM Running, Solving & CFD 0 February 25, 2014 07:58
First Order to Higher Order Blending Factor NormalVector FLUENT 3 April 3, 2013 15:43
2nd order upwind vs 2nd order upwind!!! Far Main CFD Forum 7 March 14, 2013 13:29
1st order vs 2nd order ken FLUENT 8 March 14, 2013 04:43
First order simulation better than second order Torque_Converter CFX 7 January 8, 2013 05:07


All times are GMT -4. The time now is 01:47.