|
[Sponsors] |
[Other] Problem with mesh scaling in cavitatingFoam |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
New Member
Mark Shepherd
Join Date: Jan 2012
Posts: 2
Rep Power: 0 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#2 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 14 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 14 ![]() |
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: http://www.cfd-online.com/Forums/ope...w-problem.html And more about inletOutlet here: http://www.cfd-online.com/Forums/ope...plication.html Last edited by Irish09; January 27, 2012 at 14:44. |
|
![]() |
![]() |
![]() |
![]() |
#4 |
New Member
Mark Shepherd
Join Date: Jan 2012
Posts: 2
Rep Power: 0 ![]() |
Thanks for your reply, I really appreciate it.
|
|
![]() |
![]() |
![]() |
Tags |
conversion, floating point error |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
decomposePar problem: Cell 0contains face labels out of range | vaina74 | OpenFOAM Pre-Processing | 37 | July 20, 2020 05:38 |
[Other] Mesh Importing Problem | cuteapathy | ANSYS Meshing & Geometry | 2 | June 24, 2017 05:29 |
Mesh is doing some problem | prwl120 | FLUENT | 2 | May 21, 2015 14:05 |
snappyhexmesh remove blockmesh geometry | philipp1 | OpenFOAM Running, Solving & CFD | 2 | December 12, 2014 10:58 |
[snappyHexMesh] external flow with snappyHexMesh | chelvistero | OpenFOAM Meshing & Mesh Conversion | 11 | January 15, 2010 19:43 |