These are the first lines of the decomposeParDict

It always seemed to me weird, but I've always used the number of subdomains 8 for either case I run, I did not get bigger problems. To change it I have to ask to the administrator.

The case is 3D.

I suspect that you're getting an error similar to the one explained here: http://www.openfoam.org/mantisbt/view.php?id=241

Another possibility is that there aren't enough cells near the front and back patches to ensure enough cells for calculations in parallel. You can check this from the face count given by checkMesh for each patch. The number of faces will imply the number of cells associated to them.
If the number of faces for each of the two patches is lesser than 90000, then this is a very big problem. The other count is if the number of faces are more than "90000/2" or "90000/3"; the reason for this is because a single cell of thickness for a mesh sub-domain can lead to serious calculation problems.
I say this because of the numbers given by decomposePar in the lines "Number of cells".

I also suggest that your try another decomposition method, possibly "simple" or "hierarchical".

It works with the simple decomposition method, however some probes are lost.

Hi guilha,

Are the probes lost because you continued the simulation or even if you restart from t=0s?

Best regards,
Bruno

Hi

I am simulating compressor stage of a turbocharger with the rhoPimpleDyMFoam solver. running moveDynamicMesh -checkAMI was smooth without any errors which assures that my mesh rotates properly and i have defined my interfaces correctly , please point out if i am assuming this wrong.

However running the solver my simulation crashes showing this
I am not able to identify what exactly is the problem and i suppose this is not due to the AMI interfaces as moveDynamicMesh was running perfectly. I have understood after reading few threads that it might be related to my boundary conditions, fvSchemes or fvSolution but i have no idea how to correct this. Please help me solve this and let me know if you need anymore details regarding my simulation.

Thanks

Hi,

as you've got FPE in mutkWallFunctionFvPatchScalarField::calcMut(), look at the source of the wall function:

There's several possible reasons for FPE:
1. rhow[faceI] == 0
2. muw[faceI] == 0
3. k[faceCellI] < 0
4. E_*yPlus <= 0 (this is not the case, cause yPlus > yPlusLam_)

So you need to check if any of conditions 1-3 is true in your case.

Hi alexeym,

Thanks for figuring out what the problem is.

But I am not able to interpret what the above means due to my limited openfoam knowledge. Can you please explain me in a more simplified and detailed way on how do i check the above conditions.

Hi,

well, it's more-or-less clear from the piece of code, I've posted:

1. rhow is density value on the boundary
2. muw is dynamic viscosity value of the boundary (mu is calculated by thermophysical model)
3. k is turbulent kinetic energy volume field

Also as the error happens during construction of k-epsilon turbulence model, I guess, you have to double check initial values of mu and rho.

Hello, friend. Could I ask how you solved your problem in detail? I have met the same situation and maybe your solution can enlighten me. Thank you!

Dear all,
I come to this place with a similar issue. I have used buoyantBoussinesqPimpleFoam and got the following error ,
Hope someone can help me
Thank you

Quick answer: You need to revise the boundary conditions you have defined. As explained before in this thread, the error is due to a division by zero... which means that you have defined one or more field fields to use 0.

compressible solver Foam::error::printStack
 

Dear All,
I am trying to solve compressible vortex tube case as my compulsory M.E submission and my official guide has no clue about OpenFoam. I am experimenting with both 3D and 2D(axis-symmetric) mesh with various b.c's and schemes but I am getting errors with immediate crash, particularly in compressible solvers like rhoSimpleFoam, sonicFoam, and all. What I wish is to get p, T and U field solution in which you people help .I am attaching 2D mesh and the complete case along with this message I want to mail the 3D case which exceeded the upload limit.

The error report for sonicFoam is here:

Regards:
Kush Verma
kushonthego@gmail.com
9950431523

Hi,

Your simulation crashes due to floating point error, which from the stack trace seems to be from epsilon value being zero (minimum value).

Check your BC for epsilon and if there is zero, change to a number that is non-zero and realistic for the problem.

Hope this helps.

Cheers,
Antimony

Hello I have a similar issue and i am running the debug version but still can't understand the problem. i would really appreciate some guidance, please find attached my log file. heres a snippet:

/kind regards

Quick answer @Nasir: The crash occurred in the file "src/thermophysicalModels/specie/equationOfState/perfectGas/perfectGasI.H", in this piece of code:
So, either the R constant is 0, or the T value is 0. My guess is that you defined a boundary condition for the T field to be 0 or even the whole internal field is 0. Keep in mind that the units you're using are most likely in Kelvin.

Hi every one
greetings,

dear Bruno, i really enjoyed your meticulous analysis over the cases.

here is a similar error i just faced while running buoyantBoussinesqSimpleFoam in a natural convection problem.
the geometry contains a continuously bending tube, carrying natural gas as well as the surrounding hot fluid to warm up the gas.

the complex geometry within the bends limits the mesh maneuvering. and i still get this message while asking for checkMesh
.... Failed 1 mesh checks.


afterwards i get the main error, without starting to solve!
i doubt whether or not the mesh would be in charge!!!



Create time

Create mesh for time = 0


Reading g
Reading thermophysical properties

Reading field T

Reading field p_rgh

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Creating turbulence model

Selecting RAS turbulence model laminar
Reading field alphat

Calculating field g.h

No finite volume options present


SIMPLE: convergence criteria
field p_rgh tolerance 0.01
field U tolerance 1e-05
field T tolerance 0.01
field "(k|epsilon|omega)" tolerance 0.001


Starting time loop

Time = 1

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 ? at tensorField.C:?
#4 ? at ??:?
#5 ? at ??:?
#6 ? at ??:?
#7 ? at ??:?
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9 ? at ??:?
Floating point exception (core dumped)



appreciating friends' helpful comments :)

regards,
Rana

dear friends,

anyone who can give me a tip?

thanks in advance

printStack error when I use more uniformFixedGradient BC
 

Hi everyone
I want to solve a simple heat conduction with phase change (solidification) to model cooling of a steel ingot.

My boundary conditions:
Velocities =0, pressure BC=zeroGradient (at this stage im not interested in flow, just simple heat conduction is desired)

Temperature boundary conditions:
I have 5 patches.
2 of them are fixed Gradient and 3 of them are uniformFixedGradient (reading data from the text files).

My Problem:
My solver works perfect when I set 2 of 5 patches to uniformFixedGradient boundary conditions and keep the other 3 fixedGradient.
But when I apply uniformFixedGradient for 3 patches it gives me the following error:





Starting time loop

***** Time ******* = 0.0001

Courant Number mean: 0 max: 0
smoothSolver: Solving for Ux, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for p, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
DICPCG: Solving for p, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
#0 Foam::error::printStack(Foam::Ostream&) in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib64/libc.so.6"
#3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#5 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#6 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/bin/ingot4"
#7
in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/bin/ingot4"
#8
in "/home/magma/OpenFOAM/OpenFOAM-2.3.1/platforms/linux64GccDPOpt/bin/ingot4"
#9 __libc_start_main in "/lib64/libc.so.6"
#10
at /home/abuild/rpmbuild/BUILD/glibc-2.15/csu/../sysdeps/x86_64/elf/start.S:116
Floating point exception


the solver reads the thermal gradient for 3 BCs of uniformFixedGradient from 3 text files. there is no zero number there. These 3 text files are the same and they start from time zero to end of simulation (26sec).
*****my text file*****
(
(0 -15)
(5 -45)
(10 -30)
(15 -20)
(26 -32)
);
I know that "sigFpe" is related to the numeric calculation. But when I use 2 BCs instead of 3 BCs and read 2 text file instead of 3 my program works. So I think there is no problem with thermal gradient in the text file.

hanging pointer of type N4Foam11dimensionedIdEE at index 0 (size 1), cannot dereferen
 

while starting the simulation i am facing the following problem,, can anyone help me out

--> FOAM FATAL ERROR:
hanging pointer of type N4Foam11dimensionedIdEE at index 0 (size 1), cannot dereference