
[Sponsors] 
May 6, 2008, 13:16 
hi foamers,
I'm struggling

#1 
Member
Leonardo Nettis
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
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 = 1e07 Courant Number mean: 4.12403e05 max: 0.101726 DILUPBiCG: Solving for Ux, Initial residual = 6.40149e07, Final residual = 6.40149e07, No Iterations 0 DILUPBiCG: Solving for Uy, Initial residual = 8.01029e07, Final residual = 8.01029e07, No Iterations 0 DICPCG: Solving for p, Initial residual = 1, Final residual = 8.84861e07, No Iterations 287 time step continuity errors : sum local = 5.46271e17, global = 1.38422e19, cumulative = 1.38422e19 DICPCG: Solving for p, Initial residual = 0.973936, Final residual = 9.48497e07, No Iterations 173 time step continuity errors : sum local = 2.20513e15, global = 2.89127e17, cumulative = 2.90511e17 ExecutionTime = 1.96 s ClockTime = 2 s Time = 2e07 Courant Number mean: 3.21842e05 max: 0.0600543 DILUPBiCG: Solving for Ux, Initial residual = 6.38914e06, Final residual = 4.59744e10, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 6.00179e05, Final residual = 1.46503e08, No Iterations 1 DICPCG: Solving for p, Initial residual = 0.721604, Final residual = 9.80245e07, No Iterations 227 time step continuity errors : sum local = 8.18584e15, global = 2.30115e16, cumulative = 2.59166e16 DICPCG: Solving for p, Initial residual = 0.985775, Final residual = 9.32614e07, No Iterations 17 time step continuity errors : sum local = 5.72685e14, global = 1.72613e15, cumulative = 1.46696e15 ExecutionTime = 2.56 s ClockTime = 3 s Time = 3e07 Courant Number mean: 3.05743e05 max: 0.0594463 DILUPBiCG: Solving for Ux, Initial residual = 1.51317e06, Final residual = 1.98958e10, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 1.99655e06, Final residual = 7.1546e10, No Iterations 1 DICPCG: Solving for p, Initial residual = 0.998324, Final residual = 9.50503e07, No Iterations 19 time step continuity errors : sum local = 1.0566e12, global = 3.36326e15, cumulative = 4.83022e15 DICPCG: Solving for p, Initial residual = 0.994451, Final residual = 8.13027e07, No Iterations 35 time step continuity errors : sum local = 1.50461e11, global = 5.77993e15, cumulative = 1.06102e14 ExecutionTime = 2.8 s ClockTime = 3 s Time = 4e07 Courant Number mean: 0.000238724 max: 7.8394 DILUPBiCG: Solving for Ux, Initial residual = 2.80703e06, Final residual = 7.6764e07, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 4.02692e06, Final residual = 9.52703e08, No Iterations 2 DICPCG: Solving for p, Initial residual = 0.999406, Final residual = 9.43949e07, No Iterations 66 time step continuity errors : sum local = 2.91744e10, global = 1.50479e11, cumulative = 1.50585e11 DICPCG: Solving for p, Initial residual = 0.997245, Final residual = 8.13404e07, No Iterations 15 time step continuity errors : sum local = 4.73266e09, global = 1.36223e11, cumulative = 2.86809e11 ExecutionTime = 3.1 s ClockTime = 3 s    Time = 1.5e06 Courant Number mean: 1.14736e+34 max: 5.85457e+39 DILUPBiCG: Solving for Ux, Initial residual = 0.999881, Final residual = 6.64112e07, No Iterations 2 DILUPBiCG: Solving for Uy, Initial residual = 0.99987, Final residual = 1.72012e09, No Iterations 2 DICPCG: Solving for p, Initial residual = 1, Final residual = 2.10565e10, 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.30033e07, 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.6e06 Courant Number mean: 2.62689e+75 max: 1.15657e+82 DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 9.01107e16, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 0.999999, Final residual = 3.23129e16, No Iterations 1 #0 Foam::error::printStack(Foam:stream&) in "/home/nettis/OpenFOAM/OpenFOAM1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so" #1 Foam::sigFpe::sigFpeHandler(int) in "/home/nettis/OpenFOAM/OpenFOAM1.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/OpenFOAM1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so" #4 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/nettis/OpenFOAM/OpenFOAM1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so" #5 main in "/home/nettis/OpenFOAM/OpenFOAM1.4.1/applications/bin/linux64GccDPOpt/turbFoam" #6 __libc_start_main in "/lib64/libc.so.6" #7 Foam::regIOobject::readIfModified() in "/home/nettis/OpenFOAM/OpenFOAM1.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. 

May 6, 2008, 18:34 
Hi Leonardo
It seems your p

#2 
Senior Member
Join Date: Mar 2009
Posts: 248
Rep Power: 10 
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" // Pressurevelocity 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 

May 7, 2008, 05:01 
Isn't that strange, that max C

#3 
Senior Member
Kārlis Repsons
Join Date: Mar 2009
Location: Latvia
Posts: 111
Rep Power: 9 
Isn't that strange, that max Co is small, but it jumps after one pU 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..


May 7, 2008, 05:44 
Hi Leonardo,
It might happen

#4 
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 12 
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 

May 7, 2008, 06:34 
Dear Jaswinder,
Thank you f

#5 
Member
Leonardo Nettis
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
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 = 3e08 Courant Number mean: 3.33347e06 max: 0.00657521 deltaT = 1e08 DILUPBiCG: Solving for Ux, Initial residual = 1.36296e06, Final residual = 3.32131e12, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 1.75953e06, Final residual = 2.13745e11, No Iterations 1 DICPCG: Solving for p, Initial residual = 0.998479, Final residual = 8.53246e07, No Iterations 19 time step continuity errors : sum local = 8.63191e14, global = 4.77768e16, cumulative = 6.91133e16 DICPCG: Solving for p, Initial residual = 0.992286, Final residual = 8.2383e07, No Iterations 21 time step continuity errors : sum local = 1.31931e12, global = 6.4845e16, cumulative = 1.33958e15 ExecutionTime = 2.75 s ClockTime = 3 s Time = 4e08 Courant Number mean: 2.24303e05 max: 0.699335 deltaT = 1e08 DILUPBiCG: Solving for Ux, Initial residual = 3.00275e07, Final residual = 3.00275e07, No Iterations 0 DILUPBiCG: Solving for Uy, Initial residual = 3.55047e07, Final residual = 3.55047e07, No Iterations 0 DICPCG: Solving for p, Initial residual = 0.99964, Final residual = 9.06109e07, No Iterations 21 time step continuity errors : sum local = 4.41685e11, global = 1.33967e15, cumulative = 2.67925e15 DICPCG: Solving for p, Initial residual = 0.996206, Final residual = 7.902e07, No Iterations 21 time step continuity errors : sum local = 8.19495e10, global = 5.10036e16, cumulative = 2.16922e15 ExecutionTime = 2.97 s ClockTime = 3 s Time = 5e08 Courant Number mean: 0.0137644 max: 501.842 deltaT = 1.99266e11 DILUPBiCG: Solving for Ux, Initial residual = 2.36802e07, Final residual = 2.36802e07, No Iterations 0 DILUPBiCG: Solving for Uy, Initial residual = 2.71094e07, Final residual = 2.71094e07, No Iterations 0 DICPCG: Solving for p, Initial residual = 0.999998, Final residual = 9.65875e07, No Iterations 20 time step continuity errors : sum local = 3.31369e11, global = 3.57643e16, cumulative = 1.81158e15 DICPCG: Solving for p, Initial residual = 0.994866, Final residual = 9.40811e07, No Iterations 18 time step continuity errors : sum local = 6.26688e10, global = 8.61935e15, cumulative = 1.04309e14 ExecutionTime = 3.18 s ClockTime = 3 s    Time = 5.002e08 Courant Number mean: 0.00779445 max: 287.518 deltaT = 2.15895e102 DILUPBiCG: Solving for Ux, Initial residual = 2.20739e07, Final residual = 2.20739e07, No Iterations 0 DILUPBiCG: Solving for Uy, Initial residual = 2.1986e07, Final residual = 2.1986e07, No Iterations 0 DICPCG: Solving for p, Initial residual = 0.999999, Final residual = 8.94776e07, No Iterations 14 time step continuity errors : sum local = 3.09979e11, global = 4.65564e17, cumulative = 4.64666e14 DICPCG: Solving for p, Initial residual = 0.995565, Final residual = 8.20271e07, No Iterations 15 time step continuity errors : sum local = 5.475e10, global = 1.23481e15, cumulative = 4.77014e14 ExecutionTime = 10.26 s ClockTime = 11 s Time = 5.002e08 Courant Number mean: 0.00779428 max: 287.528 deltaT = 7.50866e105 DILUPBiCG: Solving for Ux, Initial residual = 2.20742e07, Final residual = 2.20742e07, No Iterations 0 DILUPBiCG: Solving for Uy, Initial residual = 2.1986e07, Final residual = 2.1986e07, No Iterations 0 DICPCG: Solving for p, Initial residual = 0.999999, Final residual = 8.0995e07, No Iterations 15 time step continuity errors : sum local = 2.80595e11, global = 1.56952e16, cumulative = 4.75444e14 DICPCG: Solving for p, Initial residual = 0.995565, Final residual = 8.4951e07, No Iterations 15 time step continuity errors : sum local = 5.67017e10, global = 2.19705e15, cumulative = 4.97415e14 ExecutionTime = 10.45 s ClockTime = 11 s Time = 5.002e08 Courant Number mean: 0.00779465 max: 287.536 deltaT = 2.61138e107 DILUPBiCG: Solving for Ux, Initial residual = 2.20741e07, Final residual = 2.20741e07, No Iterations 0 DILUPBiCG: Solving for Uy, Initial residual = 2.19859e07, Final residual = 2.19859e07, No Iterations 0 #0 Foam::error::printStack(Foam:stream&) in "/home/nettis/OpenFOAM/OpenFOAM1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so" #1 Foam::sigFpe::sigFpeHandler(int) in "/home/nettis/OpenFOAM/OpenFOAM1.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/OpenFOAM1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so" #4 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/nettis/OpenFOAM/OpenFOAM1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so" #5 main in "/home/nettis/OpenFOAM/OpenFOAM1.4.1/applications/bin/linux64GccDPOpt/turbFoam" #6 __libc_start_main in "/lib64/libc.so.6" #7 Foam::regIOobject::readIfModified() in "/home/nettis/OpenFOAM/OpenFOAM1.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 (1e6 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 

May 7, 2008, 06:41 
Hi Dragos,
I'm currently us

#6 
Member
Leonardo Nettis
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
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 1e4 or 1e5, 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 

May 7, 2008, 06:49 
Hello Leonardo,
A Good day

#7 
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17 
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 

May 7, 2008, 07:42 
Hi Philippose,
this is the

#8 
Member
Leonardo Nettis
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
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 (1e6 vs 1e2 along zdirection), 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/nettis1.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 zipup check OK. Face vertices OK. Faceface 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.04679e19 5.83977e20 2.74138e15) 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.21945e10. Maximum face area = 6.13303. Face area magnitudes OK. Min volume = 2.21945e12. Max volume = 0.0613303. Total volume = 12.7664. Cell volumes OK. Mesh nonorthogonality Max: 89.9019 average: 13.8441 *Number of severely nonorthogonal faces: 1172. Nonorthogonality check OK. <<Writing 1172 nonorthogonal faces to set nonOrthoFaces Face pyramids OK. Max skewness = 0.473894 OK. *Edges too small, min/max edge length = 8e07 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 

May 7, 2008, 09:24 
Hi Dino
Well the mesh does

#9 
Senior Member
Join Date: Mar 2009
Posts: 248
Rep Power: 10 
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 

May 7, 2008, 10:34 
Hi Leonardo,
I've noticed tha

#10 
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 12 
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 

May 7, 2008, 11:03 
High aspect ratio cells may ca

#11 
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 330
Rep Power: 11 
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 nearsonic regime and for air (or others gases, which behaviour like ideal), effect of compresibility may be significant with incmopressible regime (M=0.1)?
__________________
Winter OpenFOAM days in Moscow  http://www.opencloudconf.ru/en/oscome.html 

May 7, 2008, 11:13 
If you want to use SpalarAlmar

#12 
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 330
Rep Power: 11 
If you want to use SpalarAlmaras 1eq 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)
__________________
Winter OpenFOAM days in Moscow  http://www.opencloudconf.ru/en/oscome.html 

May 7, 2008, 12:29 
hi foamusers.
I am also fac

#13 
Senior Member
Nishant
Join Date: Mar 2009
Location: Glasgow, UK
Posts: 165
Rep Power: 9 
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 1e5. could you please suggest something about it? Nishant
__________________
Thanks and regards, Nishant 

May 7, 2008, 14:41 
Nishant Singh, can you describ

#14 
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 330
Rep Power: 11 
Nishant Singh, can you describe your case: goals, mesh, boundaries, assumptions...
what turbulence model you are using? also, please report checkMesh report.
__________________
Winter OpenFOAM days in Moscow  http://www.opencloudconf.ru/en/oscome.html 

May 7, 2008, 15:24 
Dear all,
thank you for you

#15 
Member
Leonardo Nettis
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
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 1e3 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 nacagrid generated for a similar purpose, for which an y+ has been obtained and with the nearwall cell size equal to 1e6. 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 

May 7, 2008, 15:51 
Hello again Leonardo,
First

#16 
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17 
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 nonorthogonality look frightening I must say :)! A nonorthogonality of 89 deg, is seriously pushing it! So here comes the next question....: How many Correctors (nCorrectors) and NonOrthogonal Correctors (nNonOrthogonalCorrectors) are you using for your PISO algorithm setup? I would think you would need 2 or 3 nonorthogonal 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 

May 7, 2008, 15:56 
Hi Leonardo Nettis,
1) If y

#17 
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 330
Rep Power: 11 
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 lowRe 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 zdirection, which is "empty") case can break solution. The cell thikness for 2D case should be about 110 percent of character dimension. But, i think, you have HAR not due to zdepth. 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?
__________________
Winter OpenFOAM days in Moscow  http://www.opencloudconf.ru/en/oscome.html 

May 7, 2008, 16:01 
To Philippose Rajan, Leonardo

#18 
Senior Member
Matvey Kraposhin
Join Date: Mar 2009
Location: Moscow, Russian Federation
Posts: 330
Rep Power: 11 
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 nonorthognality. (See Hrv's Thesis)
__________________
Winter OpenFOAM days in Moscow  http://www.opencloudconf.ru/en/oscome.html 

May 7, 2008, 16:07 
Hello again,
Cool :)! So n

#19 
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17 
Hello again,
Cool :)! So now that there is some quantitative backing, I would say, with 2 PISO Correctors, and more 2 nonorthogonal 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 

May 8, 2008, 02:44 
Hello Kraposhin and Philippose

#20 
Member
Leonardo Nettis
Join Date: Mar 2009
Posts: 72
Rep Power: 9 
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 zdepth"??)  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 nonorthogonal 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!! 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Problem with turbFoam  skabilan  OpenFOAM Running, Solving & CFD  2  September 29, 2008 17:43 
Turbfoam error  danie  OpenFOAM Running, Solving & CFD  2  July 30, 2008 07:45 
TurbFoam  hsieh  OpenFOAM Running, Solving & CFD  12  July 23, 2008 07:40 
Error turbFoam  jackdaniels83  OpenFOAM Running, Solving & CFD  11  June 27, 2007 14:22 
Oodles vs turbFoam  rolando  OpenFOAM Running, Solving & CFD  9  June 4, 2007 05:42 