CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Meshing & Mesh Conversion

Problem with mesh scaling in cavitatingFoam

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   January 25, 2012, 07:44
Default Problem with mesh scaling in cavitatingFoam
  #1
New Member
 
Mark Shepherd
Join Date: Jan 2012
Posts: 2
Rep Power: 0
Mark "Politecn.di Bari" is on a distinguished road
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



Mark "Politecn.di Bari" is offline   Reply With Quote

Old   January 26, 2012, 16:54
Default Mesh not actually at fault
  #2
New Member
 
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 5
Irish09 is on a distinguished road
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.
Irish09 is offline   Reply With Quote

Old   January 27, 2012, 14:23
Default Incomplete Answer Above
  #3
New Member
 
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 5
Irish09 is on a distinguished road
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 U_x_zeroGradient.jpg. By looking at the U_x_zeroGradient_rescale.jpg 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 seeU_x_inlet_Outlet.jpg

You can see more about this problem here:

Back Flow problem

And more about inletOutlet here:

inletOutlet example application

Last edited by Irish09; January 27, 2012 at 15:44.
Irish09 is offline   Reply With Quote

Old   February 17, 2012, 05:10
Default
  #4
New Member
 
Mark Shepherd
Join Date: Jan 2012
Posts: 2
Rep Power: 0
Mark "Politecn.di Bari" is on a distinguished road
Thanks for your reply, I really appreciate it.
Mark "Politecn.di Bari" is offline   Reply With Quote

Reply

Tags
conversion, floating point error

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
snappyHexMesh won't work - zeros everywhere! sc298 OpenFOAM Native Meshers: snappyHexMesh and Others 2 March 27, 2011 21:11
Dynamic Mesh Problem. Tom Clark FLUENT 9 July 7, 2010 07:56
Moving mesh problem Geon-Hong FLUENT 3 April 5, 2010 03:24
external flow with snappyHexMesh chelvistero OpenFOAM 11 January 15, 2010 20:43
Convergence problem when ustructured mesh is used. SangJin Ryu CD-adapco 3 October 5, 2000 20:26


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