Problem with mesh scaling in cavitatingFoam
 

Hi foamers,
I hope anyone can help me.

I'm trying to study cavitation in a cylindrical duct between two cubic volumes, with cavitatingFoam.
I made a structured-mesh with Gambit (.msh file) and I converted it with fluent3DMeshToFoam. If I scale the mesh in 'cm' "fluent3DMeshToFoam -scale 0.01" the application runs correctly. But when I scale it in 'mm' (-scale 0.001) I receive a floating point error.
What is the problem? Can it be the application? Is there something wrong with the installation in openSuse?
I'm using an openOffice 2.1.0 version.

Thanks in advance.


[........]
GAMG: Solving for p, Initial residual = 0.00250839, Final residual = 1.65821e-05, No Iterations 1
Predicted p max-min : 3.00001e+07 1e+07
max-min gamma: 0 0
Phase-change corrected p max-min : 3.00001e+07 1e+07
max(U) 1.06412
GAMG: Solving for p, Initial residual = 2.95936e-05, Final residual = 2.36004e-09, No Iterations 5
Predicted p max-min : 3e+07 1e+07
max-min gamma: 0 0
Phase-change corrected p max-min : 3e+07 1e+07
max(U) 1.06409


#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib64/libc.so.6"
#3 Foam::LimitedScheme<double, Foam::limitedLinearLimiter<Foam::NVDTVD>, Foam::limitFuncs::magSqr>::limiter(Foam::Geometric Field<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#4 Foam::limitedSurfaceInterpolationScheme<double>::w eights(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#5 Foam::fv::gaussConvectionScheme<double>::fvmDiv(Fo am::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#6 Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::div<double>(Foam::GeometricField<double , Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/bin/cavitatingFoam"
#7 Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::div<double>(Foam::GeometricField<double , Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/bin/cavitatingFoam"
#8 Foam::incompressible::RASModels::kOmegaSST::correc t() in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#9
in "/opt/OpenFOAM-2.1.0/platforms/linux64GccDPOpt/bin/cavitatingFoam"
#10 __libc_start_main in "/lib64/libc.so.6"
#11
at /usr/src/packages/BUILD/glibc-2.11.3/csu/../sysdeps/x86_64/elf/start.S:116
Floating point exception

Mesh not actually at fault
 

Hello Mark!

The problem is not actually with your mesh conversion process. CavitatingFoam uses a barotropic pressure/density relationship as the closure equation, which can cause problems.

As an example I ran the throttle3D case given in the tutorial and it provided this output at the last timestep (Paying attention to the density in bold):

DILUPBiCG: Solving for rho, Initial residual = 0.00221005, Final residual = 1.90523e-09, No Iterations 3
max-min rho: 844.978 830.872
max-min gamma: 0 0
DILUPBiCG: Solving for Ux, Initial residual = 0.00282893, Final residual = 4.50759e-09, No Iterations 3
DILUPBiCG: Solving for Uy, Initial residual = 0.00614116, Final residual = 1.29312e-09, No Iterations 3
max(U) 194.636
GAMG: Solving for p, Initial residual = 0.000529359, Final residual = 7.86126e-06, No Iterations 2
Predicted p max-min : 2.99601e+07 1.75042e+06
max-min gamma: 0 0
Phase-change corrected p max-min : 2.99601e+07 1.75042e+06
max(U) 194.683
GAMG: Solving for p, Initial residual = 4.61746e-05, Final residual = 3.94951e-06, No Iterations 1
Predicted p max-min : 2.99601e+07 1.74995e+06
max-min gamma: 0 0
Phase-change corrected p max-min : 2.99601e+07 1.74995e+06
max(U) 194.641
GAMG: Solving for p, Initial residual = 9.42242e-06, Final residual = 4.04713e-09, No Iterations 4
Predicted p max-min : 2.99601e+07 1.74991e+06
max-min gamma: 0 0
Phase-change corrected p max-min : 2.99601e+07 1.74991e+06
max(U) 194.639
DILUPBiCG: Solving for k, Initial residual = 0.00202477, Final residual = 3.25256e-09, No Iterations 3
bounding k, min: -4.20021 max: 2649.71 average: 33.8603
ExecutionTime = 44.89 s ClockTime = 46 s

Then I went into the blockMeshDict and changed :

convertToMeters 1.0e-3;

to

convertToMeters 1.0e-6;

And reran the case without any other changes and received a floating point exception as you did. The output from the final timestep in this case is (density in bold again):

DILUPBiCG: Solving for rho, Initial residual = 0.000143285, Final residual = 1.29513e-11, No Iterations 2
max-min rho: 12064 -47.8267
max-min gamma: 1 0
DILUPBiCG: Solving for Ux, Initial residual = 0.00775722, Final residual = 3.84031e-10, No Iterations 3
DILUPBiCG: Solving for Uy, Initial residual = 0.0151082, Final residual = 1.86256e-09, No Iterations 3
max(U) 1.69958e+07
GAMG: Solving for p, Initial residual = 9.02874e-06, Final residual = 2.00999e-18, No Iterations 1
Predicted p max-min : 2.24583e+10 -1.74084e+07
max-min gamma: 1 0
Phase-change corrected p max-min : 2.24583e+10 400
max(U) 1.69958e+07
GAMG: Solving for p, Initial residual = 3.19517e-06, Final residual = 2.13551e-18, No Iterations 1
Predicted p max-min : 2.2455e+10 -1.68611e+07
max-min gamma: 1 0
Phase-change corrected p max-min : 2.2455e+10 400
max(U) 1.69958e+07
GAMG: Solving for p, Initial residual = 4.06359e-06, Final residual = 2.08981e-18, No Iterations 1
Predicted p max-min : 2.24568e+10 -1.63087e+07
max-min gamma: 1 0
Phase-change corrected p max-min : 2.24568e+10 400
max(U) 1.69958e+07
DILUPBiCG: Solving for k, Initial residual = 0.161799, Final residual = 3.75091e-10, No Iterations 5
bounding k, min: -1.00657e+12 max: 6.65935e+12 average: 2.11468e+09
ExecutionTime = 535.35 s ClockTime = 544 s

Notice that now the density has a negative value as the minimum value. So your geometry is not actually the problem.

As to how to get around this problem I am not entirely sure. In the thermophysicalpropertiesdict you can increase the value of rhomin in order to try and get around this problem (typically 0.1 should be fine), but it may only delay the the incident unless rhomin is made to be a large value.

Incomplete Answer Above
 

I realized after my post above that there was more to the issue than what I was stating. While the problem I pointed out with the density being negative can be corrected by changing rhomin from 0.0001 to 0.1 in the throttle3D tutorial, it was not actually causing the floating point exception. The problem, I believe is with your boundary conditions. Which ones are you using?

The Throttle3D tutorial comes with a U outlet condition of zeroGradient, however this can result in backflow and therefore the floating point exception. If you look at the x-direction velocity near where the floating point exception occurs, then you see Attachment 11002. By looking at the Attachment 11003 in which the x-velocity has been scaled to enhance negative values, ie bounded at 0, you can see negative values reaching the inlet, which would cause the floating point exception.

By changing the boundary condition to:

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

you seeAttachment 11004

You can see more about this problem here:

http://www.cfd-online.com/Forums/ope...w-problem.html

And more about inletOutlet here:

http://www.cfd-online.com/Forums/ope...plication.html

Thanks for your reply, I really appreciate it.