Foam::error::PrintStack
 

hi,
i have following errormessage in OpenFoam, as solver I use BuoyantSimpleFoam. I don´t understand that error.

Maybe someone can help me?


almir@ubuntu:~/OpenFOAM/zylinder$ buoyantSimpleFoam
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.7.x |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.7.x-3776603e4c6c
Exec : buoyantSimpleFoam
Date : Jun 15 2011
Time : 12:26:48
Host : ubuntu
PID : 5430
Case : /home/almir/OpenFOAM/zylinder
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0


Reading g
Reading thermophysical properties

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>
Reading field U

Reading/calculating face flux field phi

Creating turbulence model

Selecting RAS turbulence model kOmegaSST
kOmegaSSTCoeffs
{
alphaK1 0.85034;
alphaK2 1;
alphaOmega1 0.5;
alphaOmega2 0.85616;
Prt 1;
gamma1 0.5532;
gamma2 0.4403;
beta1 0.075;
beta2 0.0828;
betaStar 0.09;
a1 0.31;
c1 10;
}

Calculating field g.h

Reading field p_rgh


Starting time loop

Time = 1

DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 0.00987294, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 0.0157, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 1, Final residual = 0.00987846, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 1, Final residual = 0.0105804, No Iterations 1
GAMG: Solving for p_rgh, Initial residual = 0.899378, Final residual = 0.00305647, No Iterations 4
time step continuity errors : sum local = 18.9686, global = -1.40909e-15, cumulative = -1.40909e-15
rho max/min : 1.22108 1.13449
DILUPBiCG: Solving for omega, Initial residual = 0.999913, Final residual = 0.0105502, No Iterations 2
bounding omega, min: -902.694 max: 24331.5 average: 741.476
DILUPBiCG: Solving for k, Initial residual = 1, Final residual = 0.0973743, No Iterations 1
bounding k, min: -0.000335494 max: 0.0031317 average: 0.000848312
ExecutionTime = 0.11 s ClockTime = 0 s

Time = 2

DILUPBiCG: Solving for Ux, Initial residual = 0.11425, Final residual = 0.00308422, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.0715711, Final residual = 2.95363e-05, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.109402, Final residual = 0.00196119, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.177633, Final residual = 0.00377685, No Iterations 1
GAMG: Solving for p_rgh, Initial residual = 0.997056, Final residual = 0.00735437, No Iterations 4
time step continuity errors : sum local = 11.1294, global = 4.01181e-15, cumulative = 2.60272e-15
rho max/min : 309747 -321318
DILUPBiCG: Solving for omega, Initial residual = 0.594095, Final residual = 0.0340323, No Iterations 1
bounding omega, min: -7.04999e+17 max: 1.99134e+09 average: -1.78979e+14
DILUPBiCG: Solving for k, Initial residual = 0.999984, Final residual = 0.0558935, No Iterations 2
bounding k, min: -7.30668e+08 max: 1.51545e+08 average: -1.226e+06
ExecutionTime = 0.15 s ClockTime = 0 s

Time = 3

DILUPBiCG: Solving for Ux, Initial residual = 0.125933, Final residual = 0.0012217, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.097672, Final residual = 0.000856571, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.130559, Final residual = 0.00122656, No Iterations 1
DILUPBiCG: Solving for h, Initial residual = 0.467341, Final residual = 0.00933279, No Iterations 1
#0 Foam::error::PrintStack(Foam::Ostream&) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::GAMGSolver::scalingFactor(Foam::Field<double >&, Foam::Field<double> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::GAMGSolver::scalingFactor(Foam::Field<double >&, Foam::lduMatrix const&, Foam::Field<double>&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#5 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#6 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libfiniteVolume.so"
#8
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/buoyantSimpleFoam"
#9 __libc_start_main in "/lib/libc.so.6"
#10
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/buoyantSimpleFoam"
Gleitkomma-Ausnahme
almir@ubuntu:~/OpenFOAM/zylinder$


greets

almir

Greetings Almir,

At the risk of sending you off in the wrong direction, you can try this answer: My program stops with an output that starts with #0 Foam::error:: PrintStack(Foam::Ostream&)

But in an attempt to send you in the right direction:

1. You should pay closer attention to the output. For example:
   Code:

   ---

   Build  : 1.7.x-3776603e4c6c
Exec  : buoyantSimpleFoam
Date  : Jun 15 2011
Time  : 12:26:48
Host  : ubuntu
PID    : 5430
Case  : /home/almir/OpenFOAM/zylinder
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

   ---

   The line in bold tells you what SigFpe is: Floating point exception @wikipedia
2. The second line in the print stack says this:
   Code:

   ---

   #1  Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"

   ---

   Which means that some bad math went about doing something wrong... in other words, division by infinite or by zero or something like that.
3. Examining the iteration outputs, you will see the following breadcrumbs about the impeding doom that looms in the solver's horizon:
   Code:

   ---

   Time = 1

DILUPBiCG:  Solving for Ux, Initial residual = 1, Final residual = 0.00987294, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 1, Final residual = 0.0157, No Iterations 1
DILUPBiCG:  Solving for Uz, Initial residual = 1, Final residual = 0.00987846, No Iterations 1
DILUPBiCG:  Solving for h, Initial residual = 1, Final residual = 0.0105804, No Iterations 1
GAMG:  Solving for p_rgh, Initial residual = 0.899378, Final residual = 0.00305647, No Iterations 4
time step continuity errors : sum local = 18.9686, global = -1.40909e-15, cumulative = -1.40909e-15
rho max/min : 1.22108 1.13449
DILUPBiCG:  Solving for omega, Initial residual = 0.999913, Final residual = 0.0105502, No Iterations 2
bounding omega, min: -902.694 max: 24331.5 average: 741.476
DILUPBiCG:  Solving for k, Initial residual = 1, Final residual = 0.0973743, No Iterations 1
bounding k, min: -0.000335494 max: 0.0031317 average: 0.000848312
ExecutionTime = 0.11 s  ClockTime = 0 s

Time = 2

DILUPBiCG:  Solving for Ux, Initial residual = 0.11425, Final residual = 0.00308422, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 0.0715711, Final residual = 2.95363e-05, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 0.109402, Final residual = 0.00196119, No Iterations 1
DILUPBiCG:  Solving for h, Initial residual = 0.177633, Final residual = 0.00377685, No Iterations 1
GAMG:  Solving for p_rgh, Initial residual = 0.997056, Final residual = 0.00735437, No Iterations 4
time step continuity errors : sum local = 11.1294, global = 4.01181e-15, cumulative = 2.60272e-15
rho max/min : 309747 -321318
DILUPBiCG:  Solving for omega, Initial residual = 0.594095, Final residual = 0.0340323, No Iterations 1
bounding omega, min: -7.04999e+17 max: 1.99134e+09 average: -1.78979e+14
DILUPBiCG:  Solving for k, Initial residual = 0.999984, Final residual = 0.0558935, No Iterations 2
bounding k, min: -7.30668e+08 max: 1.51545e+08 average: -1.226e+06
ExecutionTime = 0.15 s  ClockTime = 0 s

   ---

   As I've noted in bold+underline: rho, omega, k and continuity errors indicate that something very not physical is happening!! Expressions like über compression and super turbulence come to mind! ;)

So, to sum up: you are giving very bad boundary conditions to your case!

Best regards,
Bruno

Awesome analysis. Also solved my problem. Thanks.

Hi Foamers,

I am running twoPhaseEulerFoam and i have increased the mesh size 6000(which was in tutorial bed2) to 24000 and I am getting following error. I tried for 12000 again same.in blockMeshDict it was (30 200 1) first I have changed it to (30 400 1) then (60 400 2) an so on.Another problem is that I have to change the file 0/alpha everytime.is there any other practical solution for that?


Courant Number mean: 0.263255 max: 12.2832
Max Ur Courant Number = 3.77181e+06
Time = 0.071

DILUPBiCG: Solving for alpha, Initial residual = 1.1014e-05, Final residual = 6.17658e-11, No Iterations 33
Dispersed phase volume fraction = 0.3 Min(alpha) = -1.92847 Max(alpha) = 2.81043
DILUPBiCG: Solving for alpha, Initial residual = 0.00010103, Final residual = 5.2889e-11, No Iterations 8
Dispersed phase volume fraction = 0.3 Min(alpha) = -0.247369 Max(alpha) = 1.92082
kinTheory: max(Theta) = 1000
kinTheory: min(nua) = 1.3774e-12, max(nua) = 0.0231854
kinTheory: min(pa) = -9295.94, max(pa) = 1.14803e+09
GAMG: Solving for p, Initial residual = 0.996287, Final residual = 0.0429939, No Iterations 1
time step continuity errors : sum local = 201567, global = 28.235, cumulative = 28.235
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::GAMGSolver::scalingFactor(Foam::Field<double >&, Foam::Field<double> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 Foam::GAMGSolver::scalingFactor(Foam::Field<double >&, Foam::lduMatrix const&, Foam::Field<double>&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#5 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#6 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#8
in "/opt/openfoam210/platforms/linux64GccDPOpt/bin/twoPhaseEulerFoam"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10
in "/opt/openfoam210/platforms/linux64GccDPOpt/bin/twoPhaseEulerFoam"
Floating point exception

Please help me...sorry for stupid questions

thanksss a lot!!!

Hi all,

thanks I did it alone...

Thanks...

Hello all,

I am having a similar error in using pimpleDyMFoam.
Below is the error output:

------------------------------------
Courant Number mean: 0.00997899 max: 0.807965
deltaT = 1.32295e-104
--> FOAM Warning :
From function Time::operator++()
in file db/Time/Time.C at line 982
Increased the timePrecision from 267 to 268 to distinguish between timeNames at time 1.97982e-05
Time = 1.979823486337861903608045799352055382769322022795 67718505859375e-05

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 1.97982e-05 transformation: ((0 0 0) (1 (0 0 0.000103663)))
AMI: Creating addressing and weights between 16 source faces and 16 target faces
AMI: Patch source weights min/max/average = 1, 1.0007, 1.00035
AMI: Patch target weights min/max/average = 0.986951, 0.987248, 0.987099
smoothSolver: Solving for Ux, Initial residual = 0.140328, Final residual = 5.75579e-08, No Iterations 3
smoothSolver: Solving for Uy, Initial residual = 0.140962, Final residual = 5.70666e-08, No Iterations 3
GAMG: Solving for p, Initial residual = 0.814891, Final residual = 0.00591061, No Iterations 3
time step continuity errors : sum local = 0.00031744, global = 5.68686e-06, cumulative = 0.00082973
#0 Foam::error::printStack(Foam::Ostream&) in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::GAMGSolver::scalingFactor(Foam::Field<double >&, Foam::Field<double> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 Foam::GAMGSolver::scalingFactor(Foam::Field<double >&, Foam::lduMatrix const&, Foam::Field<double>&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#5 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#6 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#8
in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10
in "/home/alpha/OpenFOAM/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
--------------------------

Can you tell how you went along in solving the issue?

Thank you for your help.

Greetings ebah6,

You've got a whole other set of problems on your case. In bold and underlined are the major indicators of what might be wrong:

• Courant number seems just fine, or at least isn't going overboard...
• ... at the cost of having a deltaT at a magnitude of 1e-104!? I don't even know what kind of level of simulation interaction this might be, but possibly at the quark level (http://en.wikipedia.org/wiki/Quark)?
• Time precision at 268 digits... 64bit floating point can't go beyond... I can't remember right, but isn't the limit 14 or 19?
• AMI... and using 2.1.0... mmm... you're trying to use a new feature that was released on OpenFOAM 2.1.0, so bugs are bound to pop up anywhere!

So, the diagnosis is this:

1. Using an adaptive deltaT based on Courant, the solver was forced to virtually go into sub-atomic simulations, which isn't its natural operational zone. The "adaptive deltaT based on Courant" feature is usually based on the smallest cell your mesh has got. Did you run checkMesh to verify the quality of the mesh? Do you see the "minimum volume" value? Is it something like 1e-40?
2. Also, go see the first tutorial on the user guide: Increasing the mesh resolution - read that section and you will see how the cell size relates to the deltaT needed for a stable Courant number.
3. AMI, that's a new feature. If you are going to use new features, you better be ready to use the bleeding edge ... pardon, the bug fix version of OpenFOAM, namely 2.1.x, not 2.1.0 ;)
4. If it's something new to you, Always start small!!
   You didn't specify anything about the case you are trying to simulate, so I'm assuming from the results that you are trying to simulate something that is really fast moving and has really a lot of refined zones in the mesh.
   Therefore, to avoid these kinds of issues, you should always start with something more simple. For example, if you want to simulate a fast moving F-16 going at Mach 2.1 (probably doing a full afterburner free fall? :rolleyes:), you first have to start simulating a simple trapezoid that barely resembles an airplane (ahmed body?), using a very coarse mesh and going at 1m/s. Then gradually work to a more complex mesh and geometry, so you can see the gradual needs for smaller deltaT and stuff...

Best regards and good luck!
Bruno

Thank you Bruno.

I appreciate. Let me go through this and to see how I can correct my mistakes.
I will probably get back to you for more help.

My best regards.

Hello Bruno and everyone else,

Allow that I follow up on this thread for I am experience similar issues as those for which the thread was initiated.
My log file is as follows:
I also attached my initial condition files in 0.zip.

Could you please have a look at this issue.

Thanks in advance.

Look at the courant number: it's increasing a lot. I think you should reduce the `maxCo' value in the system/controlDict file.

The solution will be slower, but I think it'll works,

Greetings to all!

To add to samiam1000's answer:

• Read once again the "lid-driven cavity flow" tutorial from the user guide, sub-section 2.1.1.4, titled "Control": http://www.openfoam.org/docs/user/ca...x5-90002.1.1.4 - this explains a bit more what the Courant Number is all about.
• Still on the user guide, sub-section 2.3.6 "Time Step Control": http://www.openfoam.org/docs/user/da...#x7-560002.3.6 - there you'll find more detailed information about how to use the dynamically adjusted deltaT.

edit: I based my answer on Samuele's answer... but apparently the problem is something else, simply because the time step is being automatically adjusted! So, if the time step is automatically adjusted and the solver still crashes, then it's either: a very bad mesh; or boundary conditions; or wrong fvSchemes... Either way, please create a small example case that reproduces your problem and post it here. Otherwise, it'll just be a long and tedious guessing game :(

Best regards,
Bruno

Dear Bruno, Dear All,

thanks for the links that you added.

I think they are very useful.

Also, I do have a problem with buoyantPimpleFoam.

I am trying to impose either temerature or velocity in some cells.

I did the same with buoyanSimpleFoam, but I have problems with the steady state. Could you check the folder I modified, please?

I am attaching the latest version of my solver, here.

Thanks a lot,

Samuele

Hello Bruno,

I did some dummy test cases:
1) a square box that rotates with the AMI; structured mesh
2) same thing with unstructured mesh.
Both these cases don't seem to give any error.
3) I did my learning case with unstructured mesh; it consists on two cylindrical rotors (Darrieus). But here I run into trouble with the problem described above.
Attached are some pictures to see how the meshes look like.
For the latter case, you can see the velocity field is messing in the outer domain where no rotation is happening.

Another question I had is how to export hybrid mesh from pointwise to openfoam?
By hybrid I mean unstructured in x-y place and we extrude in the z-direction which will then be structured.
I tried that but only the structured boundary faces are exported not the unstructured ones.

Thank you for your and my best regards.

Hi ebah6,

Mmm... I'm not an expert on this subject, but this is what I can see that might be the source of the problems:

• The cylindrical paddles are very thin, which usually leads to the requirement of additional resolution.
• The sliding interface seems to be also lacking resolution, but again I'm no expert on this.
• Still associated to this previous points, why doesn't your Darrieus structure have more cells from the tips of the cylindrical surfaces to the sliding interface, just like you have in the square-box experiments?
• Replace the square version with a single thin linear paddle (basically a squished square :)), with the same space you've got on the square experiments. If it works well, then there are two kinds of tests to be done:
  1. Try making the paddle thinner, to see how thickness might affect the solver.
  2. Make the paddle longer, so the number of cells reduces between the tips of the paddle and the sliding interface.

My bet is that as soon as the paddle is too close to the sliding interface, in regards to cell count, the solver will start having serious problems.
The other theory is that the thickness of the paddles is having a very big effect on the development of vortexes... and if these are not properly solved, it's only natural that some seriously crazy "fluid pressure shocks" (not a very technical term) will occur.

Another issue might be the speed at which the rotor is running. Proper field initialization might be required to induce the solver to start with good starting values; otherwise, you probably will have to simulate starting with the rotation speed at 0 RPM.

I'm not very familiar with these solvers, but my guess is that if you only want to have an "averaging" result, then one of the LTS solvers might come in handy... although you would have to create one that would LTS with AMI...

Best regards,
Bruno

Hello,

Yes Bruno, some of the possible issues are as you mentioned; thanks for your insight.
In particular, as the body becomes thinner, I run into problems.
However, I am only encountering problems when using a turbulence model: the laminar case runs fine.
For the cases with a turbulent flow, I refined the mesh again and again but it still crashes with a skyrocketing Courant Number.
My pressing issue is that I need to deal with thin bodies, so I need to a work-around.

Also, you suggested the STL snappyHexMesh. I did that in a recent past but the sliding interfaces show step like shape dispite the refinement.

Thanks for your help.

Hi ebah6,

Mmm, if it's not the mesh, then you've got to start tuning the "fvSchemes" file and possibly the "fvSolution" one as well. Unfortunately I don't know much how to configure them properly for each scenario, so I suggest that you check all of the relevant tutorials in OpenFOAM, as well as the User Guide.

Good luck!
Bruno

Similar Quandary
 

Good Afternoon, Everyone!

I come to this place with a similar issue, and upon reading the above comments and filtering through the User Guide for more information about initial conditions for k-epsilon and about the Courant number, I'm still having a heck of a time performing a run.

Let me explain the situation to you (I can't post the 0/ files for various reasons):

A 7m long blunt object is situated in a 10m/s wind-tunnel, with the floor of the tunnel moving with it (so we're in the blunt object's reference frame). The "ground" is of species 1 (alpha1), the wind-tunnel (or atmosphere) is of species 2 (alpha2) and the blunt object is spewing species 3 out of its' side at 40m/s (alpha3).

So, in my back-of-the-envelope calculations (inspired by the User Guide), I set my initial value of k=2.5 and epsilon=0.25. I also set the initial time-step to 0.005sec, and for the sake of early testing I turned off "adjustTimeStep." With all of that said and done, it only completes one iteration of calculation, the output for which is here:

I can see where it blows up, I just don't know how to fix it!

I would much appreciate any input anyone has on this matter.
Thanks!

Greetings Edward,

OK, if you've read about the Courant number, then you should know that you should check the smallest cell size you've got:

1. Run:
   Code:

   ---

   checkMesh

   ---

2. Search for the "Minimum volume" value.

That smallest cell is the one limiting everything!

Oh, and if checkMesh tells you that you've got bad cells or faces, then that's another source of your problems ;)

Best regards,
Bruno

I had forgotten about a set of cells I had that were two orders smaller than the rest!

However, I've since decided to go a different route because this takes a painful amount of time to process. I had interFoam running on this large mesh (see checkMesh output below) on 8 CPUs, left it over-night and it had only gotten to 0.08sec by the following morning. Since my goal is a steady-state solution, I think what I want to try is to add the phase mixing of interFoam to the SIMPLE solver of simpleFoam. I took a quick look at it yesterday, and it seems like it will be a formidable task.

Any insight on the matter before I hit the ground running?
Thanks!
~Ed

Hi Edward,

Mmm, you forgot to attach your checkMesh log. ;)

Anyway, if you want the steady state solution with interFoam, then probably this is what you want: http://www.openfoam.org/version2.0.0/steady-vof.php

Best regards,
Bruno

regaeding error while running rhoSimplecFoam
 

greetings bruno and everyone ,

i am trying to simulate my case of cold flow simulation using the rhoSimplecFoam solver but after some time of run it ends with the following error ..

can you plz help me to understand where i am doin wrong ? thanks in advance :)

Greetings yash.aesi,

Not much information to work with. But from the output you've showed:
In bold are the things to take into account:

1. The pressure field/equation is not being solved properly. After 1000 iterations, it does not have a solution.
2. Minimum "epsilon" is negative. If this "epsilon" is the one for the turbulence model, then the minimum value should be positive and greater than zero.
3. SIGFPE triggered, at the sumProd method or function. In other words, it tried to do a summation and a product of 2 or more values and it went wrong, probably because one of the values was probably NaN or Inf.

All indicates that you have incorrectly defined the boundary conditions.

Best regards
Bruno

thanks bruno ,
i wl try to check BC's :)

helo bruno ,

i tried to check my BC's. Now after giving a run its goin fine but i think the problem is not solved yet as the point you mentioned in last post about the pressure is not solved yet . The output is showing as (without giving error ):

i am attaching the file of my BC's . can you please have a look on it and tell me whr i am doin wrong ??

thanks alot in advance :)

Hi Sonu,

From what I can see, the pressure in the outlet should not be defined as being of type "calculated". Because that way you have an undefined boundary on the outlet, since you say that the velocity is of type "zeroGradient".

For ideas on what the boundary conditions should be, see the tutorials on OpenFOAM and see the link "Boundary Conditions" on this page: http://foam.sourceforge.net/docs/cpp/index.html

Best regards,
Bruno

Greetings Bruno ,
thanks bruno for suggesting these link which are useful to me for better understanding .
but i already changed the outlet BC to zeroGradient then simulation keep on running its not converging . Rite now i dnt have output to show but show you other day .


Regards ,
sonu

helo
here is what is shown in the output :

this is the modified BC's pressure BC'S
thanks in advance for your concern .
Regards ,
Sonu

outlet BC for pressure should be fixedValue,assign a back pressure there.

greetings Ehsan and bruno ,

i changed my pressure outlet BC's from zeroGradient to fixedValue but now again its giving error :

now i am totally clueless whats goin wrong . can you suggest something ??

thanks

Hi Sonu,

First, please follow the instructions on my second signature link, for when you need to post output or code, namely: How to post code using [CODE]

Second, you still have epsilon values that are outside of the normal zone of operations, namely:
Third, I'm guessing that by injecting fluid at 35 m/s and 5 m/s, you have Reynold values that are extremely high. You should first study the characteristics of your geometry and flow, to assess if you are trying to simulate in the zone of subsonic, transonic or supersonic. In addition, you should check if your mesh is proper for the simulation you are trying to perform.

Last but not least, you should not jump directly to such high flow rates. With OpenFOAM, as well with anything you don't know well enough, the approach is to not jump directly into the final case set-up, because it's very unlikely that you will succeed to have a working simulation. And in that situation, you'll have too many possible reasons for the simulation to not work, making it nearly impossible to fix all of the problems in a single step. Therefore, you should gradually evolve from the simplest form of your problem, increasing the level of complexity one detail at a time.

Best regards,
Bruno

Some errors and doubts
 

I was running a compressible LES simulation when it stopped with a similar or the same error, displayed just below.

After watching the thread, I could not figure why I get the error. SigFpe, the moderator wyldckat said it maybe maths problems. But, I had the simulation stopped at 0.00128182s, running in 64 processors of 2 machines (each machine with 32 processors). However, the same simulation, but now running on 32 processors (in only one machine) has already passed the time which the previous had failed and no errors until now (0.0018 s). And the same case but with a coarser mesh, but the same Courant number, running in 64 processors gave me a similar error, and after changing from 64 to 32 processors it run alright until the end.
I also checked my mesh with the command checkMesh, the output was

It seems ok...

And, as I see from the residuals and Courant number, all of them seem alright.

Resuming, when I run simulations with two computers, this errors happens. So is there a problem, when parallel computing is being performed with processors of two machines ? I mean the communication between them ?

Greetings guilha,

To assess if the problem is related the communication between the two machines, try running with 16 cores on each machine, therefore having 32 cores in total. This way you can isolate if the problem is due to using too many cores, or a bad decomposition or if it's related to the communication.

In addition, there are a few other things that can affect this:

1. If your case has any cyclic patches, then those might be introducing the problem here.
2. Check what parameter is being used in the file "$WM_PROJECT_DIR/etc/controlDict" for the keyword "commsType".
3. What file sharing system is being used?
   1. Is it NFS? If it is, which version is it using? NFS 3 or 4?
4. What kind of connection is being used for communicating between machines? In other words: is it Ethernet or Infiniband?
5. Run a full check on the mesh:
   
   Code:

   ---

   checkMesh -allGeometry -allTopology

   ---

Best regards,
Bruno

Hello Bruno and all other FOAMers, thanks for your help and patience

I did not have time to test the communication between the machines.

Now, following your list:

1 - Yes, I have cyclic patches, my case is almost two dimensional and LES;

2 - The "commsType" is set with nonBlocking. If I change do I have to compile anything ?

3 - I know it not, I talked to the administrator and we both do not know, but probably it is because I do not understand what really means the file sharing, however it seems not to be NFS as she said we did not use it;

4 - The communication between the machines is Ethernet.

5 - It is ok, and the output is just below (checkMesh with more options).

After talking to the administrator, I got some other views of the problem. The problem can be in the decomposition, she told me that if I decompose the problem with a script (in order to use 64 processors of two machines) maybe the machines or the mpi will be prepared, and run without any problems. While I was viewing some threads titles, I saw this one
http://www.cfd-online.com/Forums/ope...ple-cores.html I do not need to do the decomposition with parallel computing but it gave me the alert, is the problem in my decomposition ? I have been doing it by simply typing decomposePar -force, and if I wish to do it with more processors do I have to change anything in the command ? I ask it because I thought I could simply write on the script the number of processors used to do the decomposition. Although I am not using scripts to do the decomposition.

And to finish, the two cases I was running, now on SINGLE MACHINES, one of them stopped with almost the same erros (almost, because I checked the messages and they have very few differences). I must remember that the two cases are the same, but one with a more refined mesh. And the one that had given the error is the most refined case, the time of simulation at which appeared the error is almost the same as a particle at the speed of U0 have traveled the distance of the whole domain 2 times. The other case, I am running to get more samples for statistic issues, and until now no problems. So I am totally dizzied. It does not seem to be anything unphysical, I mean the residuals and Courant (and the other coarser mesh gave great results), the new error message is this one:

Hi guilha,

Have you managed to the tests I suggested?

OK, special caution is necessary for cyclic patches, as explained here: Cyclic patches and parallel postprocessing problems #8

Either your case is 2D or it isn't. In OpenFOAM, "2D" is when we use front and back patches defined as "empty" and there is only one cell thickness in the Z direction.

As for LES in 2D... I vaguely remember that it's not exactly a good idea... because the turbulence is actually 3D. But then again, I vaguely remember that OpenFOAM has got one or two tutorials working with LES in 2D.

No need to rebuild. This controls how the parallel processes will handle the waiting period between data exchanges. And that's the default option, as shown here: https://github.com/OpenFOAM/OpenFOAM...ontrolDict#L58 - so there shouldn't be any problems here.

Soooo, how are you able to share the files between the two machines, while the simulation is running? I ask this because OpenFOAM does not do this automatically, unless you use the strategy described here: Running OpenFOAM in parallel with different locations for each process


Since it's only two machines, I guess that's enough.

Yes, the mesh seems to be perfectly fine.

I don't think that's the problem. The only few possible problems could be:

• Problems with the cyclic patches, as indicate in the first point.
• Using scotch vs simple vs hierarchical might be a good exercise, for making sure if it's a problem concerning the decomposition method itself.

The last occurrence of "Signal: Floating point exception" relates to the few first error messages that say "Foam::sigFpe::sigHandler(int)". This means that there was a division by 0 somewhere. More specifically, it was when:
was called, namely this method: https://github.com/OpenFOAM/OpenFOAM...siThermo.C#L33
Problem here is that there is no clear indication of which operation might have given a division by zero.


I would choose to write frequent time snapshots near the crashing time location and then visually inspect where the fields are getting high or rather low values.

Best regards,
Bruno

Hello Bruno, thank you for your analysis. I have been too much busy lately.

The test between the machines, I did not do because I can not use x processors of one machine and y processors of the other. However, I did a test (the case is the same, only has a bigger time step), and I run it in a single processor, it failed here:
I have put the previous time steps purposely, because the Courant number was growing too much. Something tells me, that this error is due to the time step. And after running this case with a smaller time step, there is no problems, at least until where I stopped (3e-05 s).

About my simulations, they are LES 3D, of course. What I meant for almost 2D, was the type of flow, which is quasi-2D.

For the cases where my time step is smaller than the one I posted in code, and running in parallel, the errors are random. And I can not have the results stored since it leads to a lot of memory usage.
But for the last test (relatively big time step) I did (which was in a single processor), the error is not random, I run the case twice and confirmed it. From the post processing, my velocity grows in a sharp corner, and this is the reason why Courant increases, but I think it is compatible with the perfect fluid solution. But in this simulation, I think it gets unstable due to the Courant increase, that is with a smaller time step it might be bounded to the stability limit.

Also I saw the function, which you told me about, the ePsiThermo. Where there is an alpha. For certains boundaries conditions (alphaSGS, muSGS and muTilda), I used a standard one (as I could not find in the literature any value for these variables) which I saw on an OpenFOAM tutorial, and they are essentially 0.

Regarding the cyclic patch, in this link http://www.cfd-online.com/Forums/ope...tml#post241413, I think I have this in the computer,
And the scotch method. Are you suggesting that I should uncomment the last line ?

Hi guilha,

The rule of thumb is to only allow a maximum Courant number of 0.5; but if still diverges, try lower values.
Higher values should only be used if you know what you are doing ;)

Honestly, I suspect that this is one of those bugs that have already been fixed in the more recent versions of OpenFOAM. If you were able to create a small test case that replicates the errors you are observing, I could test it with the more recent versions of OpenFOAM.

Like I wrote above: the maximum Courant number that should be allowed is 0.5 or lower, depending on your simulation.

Yeah, about that... don't trust the name "alpha". It tends to appear in many shapes and forms and many of them aren't even related. If I'm not mistaken, there are at least 3 kinds of alpha in OpenFOAM: as turbulence, as heat and as phase (multiphase).

Yes, uncomment that before running decomposePar. And don't forget to replace the names therein with yours, for example:
Best regards,
Bruno

Good evening,

I am again in this thread because recently I have had a wierd error. When I run my case in 16 processors or 24 (the cases tested), no problems appear, however with more processors like 30, 32 or 64 (the cases tested) it appears this error

I run the checkMesh utility with the options -allGeometry and -allTopology and everything is fine.

Hi guilha,

It could be a problem in the installation of OpenFOAM on one of the machines. Try running checkMesh in parallel, the same way you run rhoCentralFoam.

And a few questions (I don't remember the details):

1. How many cells does the mesh have?
2. Does it have any special patches/boundary conditions? Such as cyclics, mapped or wedges?
3. How many machines are being used for each processor distribution?
4. What does decomposePar tell you for the 32 and 64 decompositions?

Best regards,
Bruno

Bruno thanks a lot for your replies and all the support.

Running the checkMesh in parallel gives an error yes

My mesh has 3,136,272 cells.
I have cyclic boundary conditions.
The decomposePar I think it works perfectly fine, the output is for the 32 processors
It is 32 processors of the same machine.

In the previous post the checkMesh output was shown without the decomposition, after decomposing there is an error