[sErik]

Hej all,

I recieve this error when I execute pisoFoam:

__________________________________________________ ____________________

Calculating averages

Time = 0.00142

Courant Number mean: 3.72507e+52 max: 1.36418e+54
DILUPBiCG: Solving for Ux, Initial residual = 0.555198, Final residual = 1.81207e-06, No Iterations 35
DILUPBiCG: Solving for Uy, Initial residual = 0.882337, Final residual = 2.82071e-06, No Iterations 36
DILUPBiCG: Solving for Uz, Initial residual = 0.959453, Final residual = 2.3849e-06, No Iterations 29
DICPCG: Solving for p, Initial residual = 0.685706, Final residual = 0.0341773, No Iterations 70
time step continuity errors : sum local = 2.65701e+50, global = 1.48284e+49, cumulative = 1.38529e+49
DICPCG: Solving for p, Initial residual = 0.684507, Final residual = 9.50829e-07, No Iterations 171
time step continuity errors : sum local = 2.06627e+46, global = -1.52172e+44, cumulative = 1.38528e+49
DILUPBiCG: Solving for k, Initial residual = 0.88271, Final residual = 7.51988e-06, No Iterations 6
bounding k, min: -3.72039e+117 max: 7.6031e+117 average: 2.9493e+116
ExecutionTime = 164.59 s ClockTime = 165 s

Calculating averages

Time = 0.00143

Courant Number mean: 8.88307e+51 max: 2.84151e+53
DILUPBiCG: Solving for Ux, Initial residual = 0.856534, Final residual = 7.94225e-06, No Iterations 39
DILUPBiCG: Solving for Uy, Initial residual = 0.826641, Final residual = 9.82446e-06, No Iterations 37
DILUPBiCG: Solving for Uz, Initial residual = 0.6356, Final residual = 6.89001e-06, No Iterations 35
DICPCG: Solving for p, Initial residual = 0.702043, Final residual = 0.0343882, No Iterations 78
time step continuity errors : sum local = 6.28092e+51, global = -2.13804e+49, cumulative = -7.5276e+48
DICPCG: Solving for p, Initial residual = 0.778709, Final residual = 8.64955e-07, No Iterations 171
time step continuity errors : sum local = 5.07704e+47, global = -7.17519e+44, cumulative = -7.52832e+48
#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::PBiCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::incompressible::LESModels:neEqEddy::correc t(Foam::tmp<Foam::GeometricField<Foam::Tensor<doub le>, Foam::fvPatchField, Foam::volMesh> > const&) in "/opt/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleLESModels.so"
#6 Foam::incompressible::LESModel::correct() in "/opt/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleLESModels.so"
#7 main in "/opt/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/pisoFoam"
#8 __libc_start_main in "/lib/libc.so.6"
#9 _start at /usr/src/packages/BUILD/glibc-2.9/csu/../sysdeps/x86_64/elf/start.S:116
Gleitkomma-Ausnahme

__________________________________________________ ____________________

It's running for a while and then it crashes.
Could it be, that my Courant Number is much to hight? Or isn't there enough memory?

Have I nice weekend,
Erik

PS: I'll only be back on monday :-)

[akidess]

Yes, your simulations are diverging and the Courant number gets way out of hand. As usual, check your boundary and initial conditions, and then your numerical parameters. Time step looks like it's pretty small already, so I'm assuming that's not your problem.

[sErik]

Hi akidess,
thx for your help.

The courant number depends on the speed, the timestep and the cell size, right? But how can I improve the courant number? I have already tried even smaler time steps and also a smaler inital speed U, but with the same result.
What else could I do to make the calculation converging?

[alberto]

Originally Posted by sErik

Hi akidess,
thx for your help.

The courant number depends on the speed, the timestep and the cell size, right? But how can I improve the courant number? I have already tried even smaler time steps and also a smaler inital speed U, but with the same result.
What else could I do to make the calculation converging?

Info on CFL: http://en.wikipedia.org/wiki/Courant%E2%80%93Friedrichs%E2%80%93Lewy_condition

About your case, it would be useful to know some more details on the case and the numerical setup (fvSchemes, essentially).

Best,

[akidess]

Originally Posted by sErik

The courant number depends on the speed, the timestep and the cell size, right? But how can I improve the courant number? I have already tried even smaler time steps and also a smaler inital speed U, but with the same result.
What else could I do to make the calculation converging?

Changing the initial speed will not do a lot to fix your problem. A Courant number of ~e+52 is unphysical anyways.. As I said, check your boundary conditions and physical parameters, then come back here with more information on the problem (like Alberto said, fvSchemes would be good to look at).

[sErik]

Thank you very much, I really appreciate your help!

My case is about a pipe flow with a tube in the middle.

This is my fvSchemes file:

FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
default steadyState;
}

gradSchemes
{
default Gauss linear;
}

divSchemes
{
default none;
div(phi,U) Gauss upwind;
div(phi,T) Gauss upwind;
div(phi,k) Gauss upwind;
div(phi,epsilon) Gauss upwind;
div(phi,R) Gauss upwind;
div(R) Gauss linear;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}

laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
laplacian(kappaEff,T) Gauss linear corrected;
laplacian(DkEff,k) Gauss linear corrected;
laplacian(DepsilonEff,epsilon) Gauss linear corrected;
laplacian(DREff,R) Gauss linear corrected;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default corrected;
}

fluxRequired
{
default no;
p ;
}

I've just copied the file from the tutorial. I'm not so sure about the impact/meaning of every entry.

There are the initial conditions for U:

dimensions [0 1 -1 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
inlet
{
type fixedValue;
referenceField uniform (0.1 0 0);
value uniform (0.1 0 0);

}

outlet
{
type inletOutlet;
inletValue uniform (0 0 0);
value uniform (0 0 0);
}

frontAndBack
{
type fixedValue;
value uniform (0 0 0);
}

lowerWall
{
type fixedValue;
value uniform (0 0 0);
}

upperWall
{
type fixedValue;
value uniform (0 0 0);
}

Rohrelement_NASTRAN
{
type fixedValue;
value uniform (0 0 0);
}

}

And this one for p:

inlet
{
type zeroGradient;
}

outlet
{
type fixedValue;
value uniform 0;
}

frontAndBack
{
type zeroGradient;
}

lowerWall
{
type zeroGradient;
}

upperWall
{
type zeroGradient;
}

Rohrelement_NASTRAN
{
type zeroGradient;
}

}

And here are the boundary conditions:

6
(
frontAndBack
{
type wall;
nFaces 266;
startFace 49933;
}
inlet
{
type patch;
nFaces 154;
startFace 50199;
}
outlet
{
type patch;
nFaces 367;
startFace 50353;
}
lowerWall
{
type wall;
nFaces 100;
startFace 50720;
}
upperWall
{
type wall;
nFaces 100;
startFace 50820;
}
Rohrelement_NASTRAN
{
type wall;
nFaces 3541;
startFace 50920;
}
)

To be honest, I'm not sure about all the effects of the "type-statements" like, "wall" or "patch" in the boundary conditions or "patch", "inletOutlet" for the initial conditions - or other statements for the cases. Wwhich/how many statements are there acually, with what kind of consequences? Is there a description or something like that, where I can figure out the effects on the solution?

Sorry for the long post.