I originally ran a case using a mesh I generated in ansys meshing, however in hindsight the mesh was quite poor. I sliced the wedge so that I could fit tet elements near the centreline to better capture the geometry however I ran into the following problems:
- there appeared to be a problem at the tet/quad interface near jet centre-line
- pressure field is strongly affected by dodgy mesh
- along tet/quad interface (particularly near inlet face)
- Temperature hotspot (may be propagating from the poor solution at inlet/centreline corner)
- velocity skyrockets
- density drops
- enthalpy equation crashes
- I feel like the solver was actually doing a good job everywhere except these small regions of very high temperature which eventually caused the crash and flow appeared as if it were developing well at the nozzle exit, (although it was at low speed)
- so I was happy with my BC's and I thought that the mesh was to blame so redid mesh in ICEM using a Y-grid which created a very uniform grid that captured the wedge really well.
Using the mesh created in ICEM:
- mesh appears to be fine in ICEM (using Y-grid so no problem at the centreline)
- passes all the mesh checks, boundary file created with all appropriate patches
- cyclic side walls produce following error
--> FOAM FATAL ERROR:
face 1421 area does not match neighbour by 0.465680107795% -- possible face ordering problem.
patch:CYCLIC_1 my area:7.62418939845 neighbour area:7.6597765931 matching tolerance:0.0001
Mesh face:1728531 fc:(-2.34107382027 16.7491260428 16.7491260428)
Neighbour fc:(-2.34457131701 22.0568638939 3.52254950135e-23)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.
- however I just use cyclicAMI... OK
- now run is failing for some other reason
- use exactly the same conditions and set-up as before but now the flow is barely travelling through the nozzle, and eventually fails with this message:
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#3 exp in "/lib/i386-linux-gnu/libm.so.6"
#4 Foam::compressible::LESModels::muSgsUSpaldingWallF unctionFvPatchScalarField::evaluate(Foam::UPstream ::commsTypes) in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libcompressibleLESModels.so"
#5 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/opt/openfoam210/platforms/linuxGccDPOpt/bin/rhoPimpleFoam"
#6 Foam::compressible::LESModels::oneEqEddy::updateSu bGridScaleFields() in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libcompressibleLESModels.so"
#7 Foam::compressible::LESModels::oneEqEddy::correct( Foam::tmp<Foam::GeometricField<Foam::Tensor<double >, Foam::fvPatchField, Foam::volMesh> > const&) in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libcompressibleLESModels.so"
#8 Foam::compressible::LESModel::correct() in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libcompressibleLESModels.so"
#10 __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
Floating point exception
I feel like the code ran better with first mesh except for the hotspots that were clearly caused by numerical problems (the mesh)
- however I think it may be moving a bit fast (inlet velocity is 10m/s so after 0.002 sec flow would only have travelled 0.02m. However the whole nozzle is 0.5m and it got past the end of the nozzle)
New mesh looks way better but code runs way too slow and then just crashes
- after 0.002 sec flow barely got started in the nozzle, where as it was at the exit in the previous mesh)
I don't understand why changing the mesh would make such a massive difference? It almost seems like in the second mesh there is something blocking it (the pressure gets very high right near the inlet).
Why is the run completely different with a new mesh that is actually quite similar?
|All times are GMT -4. The time now is 09:46.|