[dinonettis]

hi foamers,

I'm struggling with turbfoam to analyze a rae2822 profile at Ma=0.1. Unfortunately, after hundreds of trials, I cannot understand which is the reason of the following behaviour in the solving phase:

-----------------------------------
Time = 1e-07

Courant Number mean: 4.12403e-05 max: 0.101726
DILUPBiCG: Solving for Ux, Initial residual = 6.40149e-07, Final residual = 6.40149e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 8.01029e-07, Final residual = 8.01029e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 1, Final residual = 8.84861e-07, No Iterations 287
time step continuity errors : sum local = 5.46271e-17, global = -1.38422e-19, cumulative = -1.38422e-19
DICPCG: Solving for p, Initial residual = 0.973936, Final residual = 9.48497e-07, No Iterations 173
time step continuity errors : sum local = 2.20513e-15, global = -2.89127e-17, cumulative = -2.90511e-17
ExecutionTime = 1.96 s ClockTime = 2 s

Time = 2e-07

Courant Number mean: 3.21842e-05 max: 0.0600543
DILUPBiCG: Solving for Ux, Initial residual = 6.38914e-06, Final residual = 4.59744e-10, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 6.00179e-05, Final residual = 1.46503e-08, No Iterations 1
DICPCG: Solving for p, Initial residual = 0.721604, Final residual = 9.80245e-07, No Iterations 227
time step continuity errors : sum local = 8.18584e-15, global = -2.30115e-16, cumulative = -2.59166e-16
DICPCG: Solving for p, Initial residual = 0.985775, Final residual = 9.32614e-07, No Iterations 17
time step continuity errors : sum local = 5.72685e-14, global = 1.72613e-15, cumulative = 1.46696e-15
ExecutionTime = 2.56 s ClockTime = 3 s

Time = 3e-07

Courant Number mean: 3.05743e-05 max: 0.0594463
DILUPBiCG: Solving for Ux, Initial residual = 1.51317e-06, Final residual = 1.98958e-10, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1.99655e-06, Final residual = 7.1546e-10, No Iterations 1
DICPCG: Solving for p, Initial residual = 0.998324, Final residual = 9.50503e-07, No Iterations 19
time step continuity errors : sum local = 1.0566e-12, global = 3.36326e-15, cumulative = 4.83022e-15
DICPCG: Solving for p, Initial residual = 0.994451, Final residual = 8.13027e-07, No Iterations 35
time step continuity errors : sum local = 1.50461e-11, global = 5.77993e-15, cumulative = 1.06102e-14
ExecutionTime = 2.8 s ClockTime = 3 s

Time = 4e-07

Courant Number mean: 0.000238724 max: 7.8394
DILUPBiCG: Solving for Ux, Initial residual = 2.80703e-06, Final residual = 7.6764e-07, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 4.02692e-06, Final residual = 9.52703e-08, No Iterations 2
DICPCG: Solving for p, Initial residual = 0.999406, Final residual = 9.43949e-07, No Iterations 66
time step continuity errors : sum local = 2.91744e-10, global = 1.50479e-11, cumulative = 1.50585e-11
DICPCG: Solving for p, Initial residual = 0.997245, Final residual = 8.13404e-07, No Iterations 15
time step continuity errors : sum local = 4.73266e-09, global = 1.36223e-11, cumulative = 2.86809e-11
ExecutionTime = 3.1 s ClockTime = 3 s

-
-
-

Time = 1.5e-06

Courant Number mean: 1.14736e+34 max: 5.85457e+39
DILUPBiCG: Solving for Ux, Initial residual = 0.999881, Final residual = 6.64112e-07, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.99987, Final residual = 1.72012e-09, No Iterations 2
DICPCG: Solving for p, Initial residual = 1, Final residual = 2.10565e-10, No Iterations 4
time step continuity errors : sum local = 3.81358e+64, global = 7.99287e+53, cumulative = 7.99287e+53
DICPCG: Solving for p, Initial residual = 1, Final residual = 1.30033e-07, No Iterations 3
time step continuity errors : sum local = 8.71925e+69, global = 1.12494e+55, cumulative = 1.20487e+55
ExecutionTime = 12.51 s ClockTime = 13 s

Time = 1.6e-06

Courant Number mean: 2.62689e+75 max: 1.15657e+82
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 9.01107e-16, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.999999, Final residual = 3.23129e-16, No Iterations 1
#0 Foam::error::printStack(Foam:stream&) in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib64/libc.so.6"
#3 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 main in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/turbFoam"
#6 __libc_start_main in "/lib64/libc.so.6"
#7 Foam::regIOobject::readIfModified() in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/turbFoam"
Errore di virgola mobile

--------------------------------

It seems that the Courant number starts to increase suddenly without reason. I've checked a lot of times the BCs and they seems to be correct.
Indeed I've analyzed a similar case with Ma=0.75 using rhoTurbFoam, and there was no problem.
I hope somebody can help me.
Thank you in advance.

LN

ps: I've set the turbulence off in this case. However I've tried with turning it "on" as well, and the behaviour is the same.

[jaswi]

Hi Leonardo

It seems your problem lies with the time step settings. If I am not wrong, in its present implememtation, turboFoam does not allows you to calculate time step automatically depending upon the maximum courant number(which can be specified in the controlDict).

change your turboFoam.C file so that it looks like this

------------
int main(int argc, char *argv[])
{

# include "setRootCase.H"

# include "createTime.H"
# include "createMesh.H"
# include "createFields.H"
# include "initContinuityErrs.H"
# include "readTimeControls.H"
# include "setInitialDeltaT.H"


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

Info<< "\nStarting time loop\n" << endl;

for (runTime++; !runTime.end(); runTime++)
{
Info<< "Time = " << runTime.timeName() << nl << endl;
# include "readTimeControls.H"
# include "readPISOControls.H"
# include "CourantNo.H"
# include "setDeltaT.H"

// Pressure-velocity PISO corrector
------------

from here onwards the stuff remains same.
Also please add the following to the controlDict of your case

writeControl adjustableRunTime;

writeInterval 0.05; or the time resolution you want to save for

runTimeModifiable yes;

adjustTimeStep yes;

maxCo 0.5;

maxDeltaT 1;

the values for maxCo and maxDeltaT are just a suggestion. select these values according to your problem setup.

Before you use the modified solver don not forget to wclean it and then wmake it.

Let me know if that worked

Regards
Jaswi

[kar]

Isn't that strange, that max Co is small, but it jumps after one p-U corr. loop? It might happen, that # include "setDeltaT.H" can't help. He is going to set small Co and hope, that something changes. By setting max Co = 0.0594463, it wouldn't change a thing..

[dmoroian]

Hi Leonardo,
It might happen that you have a very small cell somewhere in your domain. If you start from uniform (0 0 0) velocity, then it takes some time for the main stream to reach that specific part of the domain.
I would suggest you to start from an initial potential solution. In this way you can better estimate your CFL and consequently your time step.

I hope this is helpful,
Dragos

[dinonettis]

Dear Jaswinder,

Thank you for your fast reply!
I've just tried to recompile turbfoam.c according to your advice but the results are not encouraging:

--------------------------------------
-
-
-
Time = 3e-08

Courant Number mean: 3.33347e-06 max: 0.00657521
deltaT = 1e-08
DILUPBiCG: Solving for Ux, Initial residual = 1.36296e-06, Final residual = 3.32131e-12, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1.75953e-06, Final residual = 2.13745e-11, No Iterations 1
DICPCG: Solving for p, Initial residual = 0.998479, Final residual = 8.53246e-07, No Iterations 19
time step continuity errors : sum local = 8.63191e-14, global = 4.77768e-16, cumulative = 6.91133e-16
DICPCG: Solving for p, Initial residual = 0.992286, Final residual = 8.2383e-07, No Iterations 21
time step continuity errors : sum local = 1.31931e-12, global = 6.4845e-16, cumulative = 1.33958e-15
ExecutionTime = 2.75 s ClockTime = 3 s

Time = 4e-08

Courant Number mean: 2.24303e-05 max: 0.699335
deltaT = 1e-08
DILUPBiCG: Solving for Ux, Initial residual = 3.00275e-07, Final residual = 3.00275e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 3.55047e-07, Final residual = 3.55047e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 0.99964, Final residual = 9.06109e-07, No Iterations 21
time step continuity errors : sum local = 4.41685e-11, global = 1.33967e-15, cumulative = 2.67925e-15
DICPCG: Solving for p, Initial residual = 0.996206, Final residual = 7.902e-07, No Iterations 21
time step continuity errors : sum local = 8.19495e-10, global = -5.10036e-16, cumulative = 2.16922e-15
ExecutionTime = 2.97 s ClockTime = 3 s

Time = 5e-08

Courant Number mean: 0.0137644 max: 501.842
deltaT = 1.99266e-11
DILUPBiCG: Solving for Ux, Initial residual = 2.36802e-07, Final residual = 2.36802e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 2.71094e-07, Final residual = 2.71094e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 0.999998, Final residual = 9.65875e-07, No Iterations 20
time step continuity errors : sum local = 3.31369e-11, global = -3.57643e-16, cumulative = 1.81158e-15
DICPCG: Solving for p, Initial residual = 0.994866, Final residual = 9.40811e-07, No Iterations 18
time step continuity errors : sum local = 6.26688e-10, global = 8.61935e-15, cumulative = 1.04309e-14
ExecutionTime = 3.18 s ClockTime = 3 s

-
-
-

Time = 5.002e-08

Courant Number mean: 0.00779445 max: 287.518
deltaT = 2.15895e-102
DILUPBiCG: Solving for Ux, Initial residual = 2.20739e-07, Final residual = 2.20739e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 2.1986e-07, Final residual = 2.1986e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 0.999999, Final residual = 8.94776e-07, No Iterations 14
time step continuity errors : sum local = 3.09979e-11, global = -4.65564e-17, cumulative = 4.64666e-14
DICPCG: Solving for p, Initial residual = 0.995565, Final residual = 8.20271e-07, No Iterations 15
time step continuity errors : sum local = 5.475e-10, global = 1.23481e-15, cumulative = 4.77014e-14
ExecutionTime = 10.26 s ClockTime = 11 s

Time = 5.002e-08

Courant Number mean: 0.00779428 max: 287.528
deltaT = 7.50866e-105
DILUPBiCG: Solving for Ux, Initial residual = 2.20742e-07, Final residual = 2.20742e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 2.1986e-07, Final residual = 2.1986e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 0.999999, Final residual = 8.0995e-07, No Iterations 15
time step continuity errors : sum local = 2.80595e-11, global = -1.56952e-16, cumulative = 4.75444e-14
DICPCG: Solving for p, Initial residual = 0.995565, Final residual = 8.4951e-07, No Iterations 15
time step continuity errors : sum local = 5.67017e-10, global = 2.19705e-15, cumulative = 4.97415e-14
ExecutionTime = 10.45 s ClockTime = 11 s

Time = 5.002e-08

Courant Number mean: 0.00779465 max: 287.536
deltaT = 2.61138e-107
DILUPBiCG: Solving for Ux, Initial residual = 2.20741e-07, Final residual = 2.20741e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 2.19859e-07, Final residual = 2.19859e-07, No Iterations 0
#0 Foam::error::printStack(Foam:stream&) in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib64/libc.so.6"
#3 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 main in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/turbFoam"
#6 __libc_start_main in "/lib64/libc.so.6"
#7 Foam::regIOobject::readIfModified() in "/home/nettis/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/turbFoam"
Errore di virgola mobile

--------------------------------------

As you can see the problem still remains. Actually it could be that the grid is very fine near the wall (1e-6 m) and so it could make difficult to reach the convergence. However this is a feature required to obtain a wall y+ equal to 1!!
Moreover I do not have problem using the same grid with rhoTurbFoam (since in this case Ma was 0.75) and an appropriate deltaT.
Therefore I sincerely don't know which can be the reason??

thank you

dino

[dinonettis]

Hi Dragos,

I'm currently using an initial solution obtained with potentialFoam, so I do not think the problem is that.... Anyway I've tried with very small deltaT, so that initially the max Co is 1e-4 or 1e-5, but the solution is not affected by this changes: starting exactly from the 4th time step the max Co starts quickly to increase!!

thanks a lot

dino

[philippose]

Hello Leonardo,

A Good day to you :-)!

Could you post the output of "checkMesh" on the case you are trying to simulate?

And, would it be possible to see a screenshot of your mesh by any chance?

Of the two, the output of checkMesh would be currently more important I would think :-)!

Have a nice day!

Philippose

[dinonettis]

Hi Philippose,

this is the output of checkMesh! I'm using a 2D grid found on nasa.gov, and imported in OF extruding the 3rd dimension for an amount of 0.01 (based on the wing chord=1). Obviuously the problem consists in several cells with an high aspect ratio (1e-6 vs 1e-2 along z-direction), but I think that in a 2D simulation it shouldn't be a big issue.

-----------------------------------------

Exec : checkMesh . rae0.1_turb
Date : May 07 2008
Time : 13:15:51
Host : ime171
PID : 7918
Root : /home/nettis/OpenFOAM/nettis-1.4.1/run/tutorials/turbFoam
Case : rae0.1_turb
Nprocs : 1
Create time

Create polyMesh for time = constant

Time = constant

Mesh stats
points: 49776
edges: 123816
faces: 98616
internal faces: 48840
cells: 24576
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 0

Number of cells of each type:
hexahedra: 24576
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface
defaultFaces 0 0 ok (empty)
lateral_side1 24576 24888 ok (not multiply connected)
lateral_side2 24576 24888 ok (not multiply connected)
outlet 192 386 ok (not multiply connected)
wing 176 352 ok (not multiply connected)
freestream 256 514 ok (not multiply connected)

Checking geometry...
Domain bounding box: (-17.2417 -20.0001 0) (20 19.9999 0.01)
Boundary openness (1.04679e-19 5.83977e-20 2.74138e-15) OK.
***High aspect ratio cells found, Max aspect ratio: 11764.7, number of cells 2704
<<Writing 2704 cells with high aspect ratio to set highAspectRatioCells
Minumum face area = 2.21945e-10. Maximum face area = 6.13303. Face area magnitudes OK.
Min volume = 2.21945e-12. Max volume = 0.0613303. Total volume = 12.7664. Cell volumes OK.
Mesh non-orthogonality Max: 89.9019 average: 13.8441
*Number of severely non-orthogonal faces: 1172.
Non-orthogonality check OK.
<<Writing 1172 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 0.473894 OK.
*Edges too small, min/max edge length = 8e-07 2.92463, number too small: 9628
<<Writing 9984 points on short edges to set shortEdges
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : average = 1 min = 1
All face flatness OK.

Failed 1 mesh checks.

End

----------------------------

These are 2 images of the whole mesh and in detail near the wing:






Thank you

dino

[jaswi]

Hi Dino

Well the mesh does seems to show problems. I have had myself such kind of mesh related problems before and don't know yet how to solve them.

I am sure help is on its way from Philippose and I will all eyes for his next post :-).

Regards
Jaswi

[dmoroian]

Hi Leonardo,
I've noticed that you don't use any turbulence model.
You don't mention it, but if your flow is turbulent, then is not surprising that the solution diverges.

Dragos

[mkraposhin]

High aspect ratio cells may cause serious errors, i think, you must preview this cells. to to that, you must type
foamToVTK . . -cellSet highAspectRatioCells

also, you should not use cells with aspect ratio > (500 - 1000)

and may i ask you? why y+ should be 1? What turbulence modele you are using?

why are you comparing M = 0.75, which i think, is a near-sonic regime and for air (or others gases, which behaviour like ideal), effect of compresibility may be significant with incmopressible regime (M=0.1)?

[mkraposhin]

If you want to use SpalarAlmaras 1-eq model, then your y+ should be less then 1 OR greater, then 30,

also, you must check that nu_t/nu in the boundary range lie between 1 and 10 (where nu_t is turbulent dyn. viscousity and nu is laminar (constant) dyn. viscousity)

[nishant_hull]

hi foamusers.

I am also facing problem something similar to this with rhopSonicFaom solver.
I am trying to simulate the standing wave formation in rhopsonicfoam solver. Obviously in my case headers are not similar to turbfoam.c file as explained by Jaswi but I can not see courant.H header in my rhopSonic.C file.
However my case is still runing well with only changing the controldict file, WITHOUT recompiling the source. The results are also not very encouraging and it also failed in a similar fashiion!

I am applying a timevaryingFixedVaalue patch at inlet for pressure and fixed value patch for velocity (with value v=0.001m/s). My simulation is going smooth if velocity is zero. but when velocity is some value like 0.001m/s the simulation crashes with high courant number at around 0.06 sec. i m using vanLeer div scheme. and deltaT is 1e-5.

could you please suggest something about it?

Nishant

[mkraposhin]

Nishant Singh, can you describe your case: goals, mesh, boundaries, assumptions...

what turbulence model you are using?

also, please report checkMesh report.

[dinonettis]

Dear all,

thank you for your support!

-First of all, the turbulence model I'm using is LaunderSharmaKE (no wallfunctions). In the iteration I've shown it is simply turned off, since I've read in another topic that starting with turbulence off, and after reaching the value of 1e-3 for the residuals, it is faster to reach the convergence when it is turned on. However I've tried to start with "turbulence on" since the 1st iteration and the behaviour is the same.

- the wall y+ equal to 1 is a requirement in my project, I do not know the reason! However in order to obtain it I've to use no wall functions and very small cells near the wall. For this reason I've chosen a naca-grid generated for a similar purpose, for which an y+ has been obtained and with the near-wall cell size equal to 1e-6.

-Finally I've mentioned the case for Ma=0.75 since in this case the same grid did not give me any problem. I also said that I used in this case rhoTurbFoam that is a compressible solver, whilst in the Ma=0.1 case I'm using turbFoam. So my question was: if the grid is the problem why it doesn't gives problem with all the solvers??

I think that in a 2D case it is not a big problem if the cells are strongly stretched in the 3rd direction. Indeed I'm using the empty condition on the patches perpendicular to the 3rd direction...

Any other ideas??
Thank you in advance

dino

[philippose]

Hello again Leonardo,

First and foremost, I would definitely like to clarify, that I am in no way an expert :-)! Just someone who uses OpenFOAM :-)! There are people in this forum whose expertise would make me look like a baby who has just opened its eyes and looked at the world :-)!

Thank you for the checkMesh output and the Images of the mesh, though, I guess you really can't see much of the cells in the mesh :-)! But thats ok....

From the checkMesh, it looks like your mesh is indeed a 2D mesh, so thats one thing out of the way, but... the aspect ratio and the non-orthogonality look frightening I must say :-)!

A non-orthogonality of 89 deg, is seriously pushing it!

So here comes the next question....:

How many Correctors (nCorrectors) and Non-Orthogonal Correctors (nNonOrthogonalCorrectors) are you using for your PISO algorithm setup?

I would think you would need 2 or 3 non-orthogonal correctors, and 2 PISO Correctors. I am myself not too sure how the PISO Correctors ("nCorrectors") really works with respect to a mesh of your type, but I would definitely play around with these two parameters. The general suggestion in the OpenFOAM user manual is, that you don't use more than 4 PISO Correctors.


Also, I think the large variation in aspect ratio of the cells in the mesh will cause problems with your time step. A lot of your cells seem to be stretched out perpendicular to the general flow direction, which means, you would be unnecessarily increasing the courant number of that cell (if I remember right, CFL = (u * dt)/dx, with dx being in the direction of the flow through that cell....).

But again, my suggestion would be to see if you can improve your mesh if nothing else works... most of the time, if the mesh is bad, you will end up trying all sorts of permutations and combinations of solvers and settings, but end up getting frustrated at the lack of results.

Hope this helps :-)!

Enjoy!

Philippose

[mkraposhin]

Hi Leonardo Nettis,

1) If your flow is turbulent, you MUST take turblence into account. You must ALSO take in account that fact, that turbulent is ALWAYS 3D and transient (irregular and chaotic)


2) Whar is your Re number? (it's look like it is between 1000 - 3*1.0E+5), Or it is greater 3*E+5 and you must use low-Re KE models for boundary layer...

3) Incompressibility can cause many troubles, because d(rho)/d(p)->0, thus infitely small quantity of liquid leads to infitely large pressure increase (you can observe it from mass conservatibo eqn), so it is not good to compare compressible flow with M=0,75 with incompressible flow with M=0.1

4) YES, HIGH ASPECT RATIO (HAR) CELLS (EVEN in z-direction, which is "empty") case can break solution. The cell thikness for 2D case should be about 1-10 percent of character dimension. But, i think, you have HAR not due to z-depth. IT IS BIG PROBLEM FOR A 2D CASE, if some cells vave great HAR.

5) Can you send me mesh with boundaries (OpenFOAM mesh and original), so i can test it (if it's not a governmebt secret)?

6) Where do you get your mesh? Maybe it is better to generate your mesh from scratch, using geometrical properties?

[mkraposhin]

To Philippose Rajan, Leonardo Nettis:

2 PISO Correctors and 1 or 2 non orthogonal correctors is enough, the more numbers may blow up your calculations.

This correctors is artificial way to take into account transient and non-orthognality. (See Hrv's Thesis)

[philippose]

Hello again,

Cool :-)! So now that there is some quantitative backing, I would say, with 2 PISO Correctors, and more 2 non-orthogonal correctors, if the solution still blows up, then you really need to give your mesh an overhaul...

One more thing.... this is assuming that you are not making any really small, usually simple, mistake in any of your case setup files (boundary conditions, solvers, schemes, etc...). Sometimes, it also makes sense if you let someone else go through your case files.... they might catch something you have missed simply by virtue of having looked at it too much :-)!

Philippose

[dinonettis]

Hello Kraposhin and Philippose:

- As I aforesaid the iteration process keeps this strange behaviour also in the case turbulence is set "on"!

- Re=1e6.... Isn't LaunderSharmaKE a low Reynolds number turbulence model?

- Therefore a compressible case is less sensitive to an eventual 2D mesh with BIG PROBLEMS?? (why do you think I have "HAR not due to z-depth"??)

- you can download the mesh here: http://www.grc.nasa.gov/WWW/wind/val.../raetaf04.html
Once you have this 2D mesh it is possible to import it in OF using plot3dToFoam (the last version created by mattjis janssenn and available on the forum) imposing the 3rd direction size.

I'll try to modify both PISO and non-orthogonal correctors and if I'll still have problems I'll make some corrections to the grid, although I sincerely do not know what I can change...

Thank you very much!!