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 structuredmesh 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.65821e05, No Iterations 1 Predicted p maxmin : 3.00001e+07 1e+07 maxmin gamma: 0 0 Phasechange corrected p maxmin : 3.00001e+07 1e+07 max(U) 1.06412 GAMG: Solving for p, Initial residual = 2.95936e05, Final residual = 2.36004e09, No Iterations 5 Predicted p maxmin : 3e+07 1e+07 maxmin gamma: 0 0 Phasechange corrected p maxmin : 3e+07 1e+07 max(U) 1.06409 #0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM2.1.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM2.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/OpenFOAM2.1.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so" #4 Foam::limitedSurfaceInterpolationScheme<double>::w eights(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/OpenFOAM2.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/OpenFOAM2.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/OpenFOAM2.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/OpenFOAM2.1.0/platforms/linux64GccDPOpt/bin/cavitatingFoam" #8 Foam::incompressible::RASModels::kOmegaSST::correc t() in "/opt/OpenFOAM2.1.0/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so" #9 in "/opt/OpenFOAM2.1.0/platforms/linux64GccDPOpt/bin/cavitatingFoam" #10 __libc_start_main in "/lib64/libc.so.6" #11 at /usr/src/packages/BUILD/glibc2.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.90523e09, No Iterations 3 maxmin rho: 844.978 830.872 maxmin gamma: 0 0 DILUPBiCG: Solving for Ux, Initial residual = 0.00282893, Final residual = 4.50759e09, No Iterations 3 DILUPBiCG: Solving for Uy, Initial residual = 0.00614116, Final residual = 1.29312e09, No Iterations 3 max(U) 194.636 GAMG: Solving for p, Initial residual = 0.000529359, Final residual = 7.86126e06, No Iterations 2 Predicted p maxmin : 2.99601e+07 1.75042e+06 maxmin gamma: 0 0 Phasechange corrected p maxmin : 2.99601e+07 1.75042e+06 max(U) 194.683 GAMG: Solving for p, Initial residual = 4.61746e05, Final residual = 3.94951e06, No Iterations 1 Predicted p maxmin : 2.99601e+07 1.74995e+06 maxmin gamma: 0 0 Phasechange corrected p maxmin : 2.99601e+07 1.74995e+06 max(U) 194.641 GAMG: Solving for p, Initial residual = 9.42242e06, Final residual = 4.04713e09, No Iterations 4 Predicted p maxmin : 2.99601e+07 1.74991e+06 maxmin gamma: 0 0 Phasechange corrected p maxmin : 2.99601e+07 1.74991e+06 max(U) 194.639 DILUPBiCG: Solving for k, Initial residual = 0.00202477, Final residual = 3.25256e09, 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.0e3; to convertToMeters 1.0e6; 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.29513e11, No Iterations 2 maxmin rho: 12064 47.8267 maxmin gamma: 1 0 DILUPBiCG: Solving for Ux, Initial residual = 0.00775722, Final residual = 3.84031e10, No Iterations 3 DILUPBiCG: Solving for Uy, Initial residual = 0.0151082, Final residual = 1.86256e09, No Iterations 3 max(U) 1.69958e+07 GAMG: Solving for p, Initial residual = 9.02874e06, Final residual = 2.00999e18, No Iterations 1 Predicted p maxmin : 2.24583e+10 1.74084e+07 maxmin gamma: 1 0 Phasechange corrected p maxmin : 2.24583e+10 400 max(U) 1.69958e+07 GAMG: Solving for p, Initial residual = 3.19517e06, Final residual = 2.13551e18, No Iterations 1 Predicted p maxmin : 2.2455e+10 1.68611e+07 maxmin gamma: 1 0 Phasechange corrected p maxmin : 2.2455e+10 400 max(U) 1.69958e+07 GAMG: Solving for p, Initial residual = 4.06359e06, Final residual = 2.08981e18, No Iterations 1 Predicted p maxmin : 2.24568e+10 1.63087e+07 maxmin gamma: 1 0 Phasechange corrected p maxmin : 2.24568e+10 400 max(U) 1.69958e+07 DILUPBiCG: Solving for k, Initial residual = 0.161799, Final residual = 3.75091e10, 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
3 Attachment(s)
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 xdirection velocity near where the floating point exception occurs, then you see Attachment 11002. By looking at the Attachment 11003 in which the xvelocity 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.cfdonline.com/Forums/ope...wproblem.html And more about inletOutlet here: http://www.cfdonline.com/Forums/ope...plication.html 
Thanks for your reply, I really appreciate it.

All times are GMT 4. The time now is 12:30. 