CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   Main CFD Forum (https://www.cfd-online.com/Forums/main/)
-   -   Help with solving floating point exception crash. (https://www.cfd-online.com/Forums/main/132007-help-solving-floating-point-exception-crash.html)

rendagar March 24, 2014 08:02

Help with solving floating point exception crash. [SOLVED]
 
2 Attachment(s)
Hi,

Does someone have any idea what is casing the crash I'm experiencing when using chtMultiRegionFoam on a case I have build using OpenFOAM 2.3.0 (using openSuse 13.1). I know the error is a floating point exception (which is caused by dividing by 0 or some other invalid math operation) however I'm unable to find the root cause. It error I have is the following:

Code:

Solving for fluid region airEnclosure
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG:  Solving for Ux, Initial residual = 1, Final residual = 1.3008103e-11, No Iterations 2
DILUPBiCG:  Solving for Uy, Initial residual = 1, Final residual = 1.2358456e-09, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 1, Final residual = 1.7628265e-11, No Iterations 2
DILUPBiCG:  Solving for h, Initial residual = 1, Final residual = 5.3365854e-11, No Iterations 2
Min/max T:300 350
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  in "/lib64/libc.so.6"
#3  Foam::fanFvPatchField<double>::calcFanJump() at ??:?
#4  Foam::fanFvPatchField<double>::updateCoeffs() at ??:?
#5  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::updateCoeffs() at ??:?
#6  Foam::fvMatrix<double>::fvMatrix(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) at ??:?
#7  Foam::fv::EulerDdtScheme<double>::fvmDdt(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#8  Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::ddt<double>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#9 
 at ??:?
#10  __libc_start_main in "/lib64/libc.so.6"
#11 
 at /home/abuild/rpmbuild/BUILD/glibc-2.18/csu/../sysdeps/x86_64/start.S:125
Floating point exception

and it is generated by the GAMG solver trying to solve for p_rgh when including a fan type boundary condition. The settings for the simulation where taken from a similar case I have made which runs without a problem. Both cases are based on the multiRegionHeater tutorial.

The idea behind the simulation is to simulate forced air flow and heat conduction inside an enclosure.

Below is a more detailed description of the work flow I use to generate the error.

Code:

> ./Allrun
> Running blockMesh on /mnt/WIN/51640_2060/05_OpenFoam/failCase
> Running topoSet on /mnt/WIN/51640_2060/05_OpenFoam/failCase
> Running splitMeshRegions on /mnt/WIN/51640_2060/05_OpenFoam/failCase
> Running createBaffles on /mnt/WIN/51640_2060/05_OpenFoam/failCase

There are no warmings in the log files created except for createBaffles which reports

Code:

--> FOAM Warning :
    From function createBaffles
    in file createBaffles.C at line 773
    Setting field on boundary faces to zero.
You might have to edit these fields.

what I do not believe to be a problem.

However when I try to run chtMultiRegionFoam I get the floating point exception mentioned above.

When I comment out the fan boundary condition from system/airEnclosure/createBafflesDict the simulation runs without a problem (however also without the forced air flow I want to include) so I know there is a problem somewhere there.

I have tried moving the simulation domain to just positive axis, changed the shape and location of the fan boundary, increasing the number of cells in the domain and trying to use a staggered grid (actually the staggered grid was the initial case and I was hoping it was the cause of the error, no luck there though) and investigated changing the fan boundary condition. Nothing so far has solved the error.

I have added 2 cases for anyone to investigate.

failCase --> This fails like described above.
fanCase --> Similar setup (no heat source) but runs without a problem. Proving the simulation is possible.

The main differences between the two cases above is that the failCase includes a airOutside region around the enclosure. Also the enclosure is created using topoSet instead of it being the entire simulation domain as in the fanCase case.

If anyone could spare some time to investigate the error it would be very much appreciated. I've been stuck on this for some time now.

Regards,

rendagar March 26, 2014 07:34

Solved yet not understood
 
I managed to solve the problem. Don't quite understand it yet but perhaps some investigation into the fan boundary condition or the chtMultiregionFoam solver will prove insightful.

The problem is solved by removing the fan type boundary condition on fan_half0 and fan_half1 in 0/airEnclosure/p and replacing it with a cyclic one (or probably anything, they don't seem to affect the simulation). The fan_half* conditions in 0/airEnclosure/p_rgh remain the same i.e.

Code:

fan_half0
{
    type            fan;
    patchType      cyclic;
    jump            uniform 0;
    value          uniform 0;
    jumpTable      polynomial 1 ( ( 100 0 ) );
}
fan_half1
{
    type            fan;
    patchType      cyclic;
    value          uniform 0;
}

Now there is no crash when running chtMultiRegionFoam and the initial results show there is both forced air flow and heating of the air. Apparently the values in p do not influence the results of this solver (or at least not noticeably) but they are capable of crashing the solver.

Now on to refining the boundary conditions and solvers e.t.c.


All times are GMT -4. The time now is 04:53.