|
[Sponsors] |
[snappyHexMesh] Crash with snappyHexMesh in Foam::triSurface::readSTLASCII |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
August 13, 2014, 10:38 |
Crash with snappyHexMesh in Foam::triSurface::readSTLASCII
|
#1 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
Hi, I'm introducing into the world of CFD, I'll finish my engineering in January and I will make my final work of an introduction in CFD. Now I'm practicing and testing some things and when I tried to mesh a model with snappyHexMesh using a snappyHexMeshdict file which we worked in class as a template I got the following error:
#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::sigSegv::sigHandler(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #2 in "/lib/x86_64-linux-gnu/libc.so.6" #3 yyFlexLexer::yy_try_NUL_trans(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #4 STLLexer::lex() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #5 Foam::triSurface::readSTLASCII(Foam::fileName const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #6 Foam::triSurface::readSTL(Foam::fileName const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #7 Foam::triSurface::read(Foam::fileName const&, Foam::word const&, bool) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #8 Foam::triSurface::triSurface(Foam::fileName const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #9 Foam::triSurfaceMesh::triSurfaceMesh(Foam::IOobjec t const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libmeshTools.so" #10 Foam::searchableSurface::adddictConstructorToTable <Foam::triSurfaceMesh>::New(Foam::IOobject const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libmeshTools.so" #11 Foam::searchableSurface::New(Foam::word const&, Foam::IOobject const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libmeshTools.so" #12 Foam::searchableSurfaces::searchableSurfaces(Foam: :IOobject const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libmeshTools.so" #13 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/snappyHexMesh" #14 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #15 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/snappyHexMesh" Segmentation fault (core dumped) Could someone give me some help here? thank you all. |
|
August 13, 2014, 15:04 |
|
#3 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
Sure Nucleophobe, thanks for your time.
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.1.1 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object snappyHexMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // // Which of the steps to run castellatedMesh true; snap true; addLayers true; // Geometry. Definition of all surfaces. All surfaces are of class // searchableSurface. // Surfaces are used // - to specify refinement for any mesh cell intersecting it // - to specify refinement for any mesh cell inside/outside/near // - to 'snap' the mesh boundary to the surface geometry { PTri.stl { type triSurfaceMesh; name PTri; } refinementBox { type searchableBox; min (-0.5 -0.2 -0.5); max (2.5 0.5 2.5); } }; // Settings for the castellatedMesh generation. castellatedMeshControls { // Refinement parameters // ~~~~~~~~~~~~~~~~~~~~~ // If local number of cells is >= maxLocalCells on any processor // switches from from refinement followed by balancing // (current method) to (weighted) balancing before refinement. maxLocalCells 100000; // Overall cell limit (approximately). Refinement will stop immediately // upon reaching this number so a refinement level might not complete. // Note that this is the number of cells before removing the part which // is not 'visible' from the keepPoint. The final number of cells might // actually be a lot less. maxGlobalCells 2000000; // The surface refinement loop might spend lots of iterations refining just a // few cells. This setting will cause refinement to stop if <= minimumRefine // are selected for refinement. Note: it will at least do one iteration // (unless the number of cells to refine is 0) minRefinementCells 10; // Allow a certain level of imbalance during refining // (since balancing is quite expensive) // Expressed as fraction of perfect balance (= overall number of cells / // nProcs). 0=balance always. maxLoadUnbalance 0.10; // Number of buffer layers between different levels. // 1 means normal 2:1 refinement restriction, larger means slower // refinement. nCellsBetweenLevels 3; // Explicit feature edge refinement // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Specifies a level for any cell intersected by its edges. // This is a featureEdgeMesh, read from constant/triSurface for now. features ( //{ // file "someLine.eMesh"; // level 2; //} ); // Surface based refinement // ~~~~~~~~~~~~~~~~~~~~~~~~ // Specifies two levels for every surface. The first is the minimum level, // every cell intersecting a surface gets refined up to the minimum level. // The second level is the maximum level. Cells that 'see' multiple // intersections where the intersections make an // angle > resolveFeatureAngle get refined up to the maximum level. refinementSurfaces { PTri { // Surface-wise min and max refinement level level (7 7); } } // Resolve sharp angles resolveFeatureAngle 30; // Region-wise refinement // ~~~~~~~~~~~~~~~~~~~~~~ // Specifies refinement level for cells in relation to a surface. One of // three modes // - distance. 'levels' specifies per distance to the surface the // wanted refinement level. The distances need to be specified in // descending order. // - inside. 'levels' is only one entry and only the level is used. All // cells inside the surface get refined up to the level. The surface // needs to be closed for this to be possible. // - outside. Same but cells outside. refinementRegions { refinementBox { mode inside; levels ((1E15 4)); } } // Mesh selection // ~~~~~~~~~~~~~~ // After refinement patches get added for all refinementSurfaces and // all cells intersecting the surfaces get put into these patches. The // section reachable from the locationInMesh is kept. // NOTE: This point should never be on a face, always inside a cell, even // after refinement. locationInMesh (0.0001232 0.232432 0.005424321); // Whether any faceZones (as specified in the refinementSurfaces) // are only on the boundary of corresponding cellZones or also allow // free-standing zone faces. Not used if there are no faceZones. allowFreeStandingZoneFaces true; } // Settings for the snapping. snapControls { //- Number of patch smoothing iterations before finding correspondence // to surface nSmoothPatch 3; //- Relative distance for points to be attracted by surface feature point // or edge. True distance is this factor times local // maximum edge length. tolerance 4.0; //- Number of mesh displacement relaxation iterations. nSolveIter 0; //- Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 5; //- Highly experimental and wip: number of feature edge snapping // iterations. Leave out altogether to disable. // Do not use here since mesh resolution too low and baffles present //nFeatureSnapIter 10; } // Settings for the layer addition. addLayersControls { // Are the thickness parameters below relative to the undistorted // size of the refined cell outside layer (true) or absolute sizes (false). relativeSizes true; // Per final patch (so not geometry!) the layer information layers { "(PTri).*" { nSurfaceLayers 1; } } // Expansion factor for layer mesh expansionRatio 1.0; //- Wanted thickness of final added cell layer. If multiple layers // is the // thickness of the layer furthest away from the wall. // Relative to undistorted size of cell outside layer. // is the thickness of the layer furthest away from the wall. // See relativeSizes parameter. finalLayerThickness 0.3; //- Minimum thickness of cell layer. If for any reason layer // cannot be above minThickness do not add layer. // Relative to undistorted size of cell outside layer. minThickness 0.1; //- If points get not extruded do nGrow layers of connected faces that are // also not grown. This helps convergence of the layer addition process // close to features. // Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x) nGrow 0; // Advanced settings //- When not to extrude surface. 0 is flat surface, 90 is when two faces // make straight angle. featureAngle 30; //- Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 3; // Number of smoothing iterations of surface normals nSmoothSurfaceNormals 1; // Number of smoothing iterations of interior mesh movement direction nSmoothNormals 3; // Smooth layer thickness over surface patches nSmoothThickness 10; // Stop layer growth on highly warped cells maxFaceThicknessRatio 0.5; // Reduce layer growth where ratio thickness to medial // distance is large maxThicknessToMedialRatio 0.3; // Angle used to pick up medial axis points // Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x. minMedianAxisAngle 90; // Create buffer region for new layer terminations nBufferCellsNoExtrude 0; // Overall max number of layer addition iterations. The mesher will exit // if it reaches this number of iterations; possibly with an illegal // mesh. nLayerIter 50; } // Generic mesh quality settings. At any undoable phase these determine // where to undo. meshQualityControls { //- Maximum non-orthogonality allowed. Set to 180 to disable. maxNonOrtho 65; //- Max skewness allowed. Set to <0 to disable. maxBoundarySkewness 20; maxInternalSkewness 4; //- Max concaveness allowed. Is angle (in degrees) below which concavity // is allowed. 0 is straight face, <0 would be convex face. // Set to 180 to disable. maxConcave 80; //- Minimum pyramid volume. Is absolute volume of cell pyramid. // Set to a sensible fraction of the smallest cell volume expected. // Set to very negative number (e.g. -1E30) to disable. minVol 1e-13; //- Minimum quality of the tet formed by the face-centre // and variable base point minimum decomposition triangles and // the cell centre. This has to be a positive number for tracking // to work. Set to very negative number (e.g. -1E30) to // disable. // <0 = inside out tet, // 0 = flat tet // 1 = regular tet minTetQuality 1e-30; //- Minimum face area. Set to <0 to disable. minArea -1; //- Minimum face twist. Set to <-1 to disable. dot product of face normal //- and face centre triangles normal minTwist 0.02; //- minimum normalised cell determinant //- 1 = hex, <= 0 = folded or flattened illegal cell minDeterminant 0.001; //- minFaceWeight (0 -> 0.5) minFaceWeight 0.02; //- minVolRatio (0 -> 1) minVolRatio 0.01; //must be >0 for Fluent compatibility minTriangleTwist -1; // Advanced //- Number of error distribution iterations nSmoothScale 4; //- amount to scale back displacement at error points errorReduction 0.75; } // Advanced // Flags for optional output // 0 : only write final meshes // 1 : write intermediate meshes // 2 : write volScalarField with cellLevel for postprocessing // 4 : write current intersections as .obj files debug 0; // Merge tolerance. Is fraction of overall bounding box of initial mesh. // Note: the write tolerance needs to be higher than this. mergeTolerance 1e-6; // ************************************************** *********************** // |
|
August 13, 2014, 15:18 |
|
#4 |
Member
|
Okay, I don't see anything alarming there.
Is "PTri.stl" an ASCII file, or binary? If it's binary, try converting it to an ASCII file and see if that changes your error output (you can do this with the surfaceConvert utility). |
|
August 13, 2014, 15:36 |
|
#5 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
I haven't understood the question I modeled it in solidworks and then I saved it in .stl format.
|
|
August 13, 2014, 15:41 |
|
#6 |
Member
|
Okay, open the STL file in a text editor (notepad on Windows, vim/emacs/nano/gedit on Linux...). Do you see lines of code like this:
Code:
solid facet normal ni nj nk outer loop vertex v1x v1y v1z vertex v2x v2y v2z vertex v3x v3y v3z endloop endfacet ....... So, try running: Code:
mv PTri.stl PTri.binary.stl surfaceConvert -scale 1 PTri.binary.stl PTri.stl -Nuc |
|
August 13, 2014, 16:06 |
|
#7 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
The file its binary, whats the difference between binary and ascii file?
Executing the second command i get this error: Reading : "PTri.binary.stl" #0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::sigSegv::sigHandler(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #2 in "/lib/x86_64-linux-gnu/libc.so.6" #3 yyFlexLexer::yy_try_NUL_trans(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #4 STLLexer::lex() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #5 Foam::triSurface::readSTLASCII(Foam::fileName const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #6 Foam::triSurface::readSTL(Foam::fileName const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #7 Foam::triSurface::read(Foam::fileName const&, Foam::word const&, bool) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #8 Foam::triSurface::triSurface(Foam::fileName const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libtriSurface.so" #9 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/surfaceConvert" #10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #11 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/surfaceConvert" Segmentation fault (core dumped) PD: I'm running openfoam from an ubuntu pendrive, I don't know if that could be the problem. |
|
August 13, 2014, 16:13 |
|
#8 |
Member
|
Okay, maybe try renaming the file extension to .stlb? See thread below:
http://www.cfd-online.com/Forums/ope...ascii-stl.html Otherwise consider posting the STL file. OpenFOAM seems to crash upon trying to read it. |
|
August 13, 2014, 18:20 |
|
#9 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
Good, it worked, I changed the name to PTri.stlb and that way openfoam has been able to work with that file. The first think i have done is change the format to ascii with your previous command surfaceconverter. Once I had the model in ascii format i have tried to mesh again and now i get that new error:
--> FOAM FATAL ERROR: Multiple outside loops: 0 ( ) From function combineFaces::getOutsideFace(const indirectPrimitivePatch&) in file polyTopoChange/polyTopoChange/combineFaces.C at line 420. FOAM aborting #0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::error::abort() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #2 Foam::combineFaces::getOutsideFace(Foam::Primitive Patch<Foam::face, Foam::IndirectList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicMesh.so" #3 Foam::combineFaces::validFace(double, Foam::PrimitivePatch<Foam::face, Foam::IndirectList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicMesh.so" #4 Foam::combineFaces::getMergeSets(double, double, Foam::HashSet<int, Foam::Hash<int> > const&) const in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicMesh.so" #5 Foam::meshRefinement::mergePatchFacesUndo(double, double, Foam::List<int> const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libautoMesh.so" #6 Foam::autoSnapDriver::doSnap(Foam::dictionary const&, Foam::dictionary const&, double, Foam::snapParameters const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libautoMesh.so" #7 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/snappyHexMesh" #8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #9 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/snappyHexMesh" Aborted (core dumped) I have found that thread http://www.cfd-online.com/Forums/ope...ide-loops.html but i think that I don't really understand what i have to modify. Thanks for your time again PD: One question, the numbers introduced into the blockMeshdict or snappyHexMeshdict are in meters or millimeters? |
|
August 13, 2014, 18:30 |
|
#10 |
Member
|
Can you post a screenshot of your case geometry? Are you doing external flow, or internal flow? You may need to refine your blockMesh...
Also, did sHM (snappyHexMesh) write out any data to folders? You should see a folder for each step in the process: 1 - castellated mesh, 2 - snapped mesh, and 3 - mesh with layers. If you got any of these folders to output, try loading the results in ParaView to see if that gives any clues. Also, for your earlier question: http://www.cs.umd.edu/class/sum2003/.../asciiBin.html |
|
August 13, 2014, 18:49 |
|
#11 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
External flow, here you have a screenshot of my model, a silly example for practice:
And that's the background mesh that I use: sHM has created one folder, the castellated mesh one (1). When I try to represent it on paraFoam appears an empty prism. Otherwise, the numbers that are introduced into blockMeshdict or sHM are in meters or millimeters? And thanks for the link |
|
August 20, 2014, 11:51 |
|
#12 |
Senior Member
|
The numbers are always in meters: http://www.openfoam.org/docs/user/bl...#x25-1420005.3
__________________
Blog: sourceflux.de/blog "The OpenFOAM Technology Primer": sourceflux.de/book Twitter: @sourceflux_de Interested in courses on OpenFOAM? |
|
August 20, 2014, 12:17 |
|
#13 |
Member
|
H25E,
I think you block mesh may be a *little* too coarse for your case. Try increasing you refinement, or decreasing the size of your domain (since this is just a test case). Also, make sure that your "locationInMesh" is set correctly. If this point is outside of the main domain or inside of your prism, you will run into problems. Good luck, keep us posted on your progress. |
|
August 23, 2014, 05:22 |
|
#14 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
Thanks you all,
Solidworks allows to work with meters and millimeters and for some reason, I suppose that an error in the conversion to stl, my model had 2 km length instead of 2 m. Solving that, correcting blockMeshdict and sHMdict to the new geometry of 2 m, and creating a denser mesh I get the following error when I launch sHM: Create mesh for time = 0 Read mesh in = 1.55 s Overall mesh bounding box : (-1 -0.5 -0.5) (3 1 4) Relative tolerance : 1e-06 Absolute matching distance : 6.20484e-06 Reading refinement surfaces. Read refinement surfaces in = 0 s Reading refinement shells. Refinement level 3 for all cells inside refinementBox Read refinement shells in = 0 s Setting refinement level of surface to be consistent with shells. Checked shell refinement in = 0 s Reading features. Read features in = 0 s Determining initial surface intersections ----------------------------------------- --> FOAM FATAL ERROR: Number of cells in mesh:250000 does not equal size of cellLevel:1 This might be because of a restart with inconsistent cellLevel. From function hexRef8::getLevel0EdgeLength() const in file polyTopoChange/polyTopoChange/hexRef8.C at line 357. FOAM aborting #0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::error::abort() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #2 Foam::hexRef8::getLevel0EdgeLength() const in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicMesh.so" #3 Foam::hexRef8::hexRef8(Foam:olyMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::refinementHistory const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicMesh.so" #4 Foam::meshRefinement::meshRefinement(Foam::fvMesh& , double, bool, Foam::refinementSurfaces const&, Foam::refinementFeatures const&, Foam::shellSurfaces const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libautoMesh.so" #5 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/snappyHexMesh" #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #7 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/snappyHexMesh" Aborted (core dumped) |
|
August 25, 2014, 22:38 |
|
#15 |
Member
|
H25E,
It sounds like you need to clean up your case directory. You shouldn't have any directories with numbers as names (remove 0, 1,2,3, etc. ). After removing all the extra directories, run blockMesh, and then try snappyHexMesh again. More information here: http://www.cfd-online.com/Forums/ope...celllevel.html If you run into anymore trouble, I recommend you do a quick forum search with keywords from your error message, as you might get answers faster that way. Good luck again! The first time is the hardest, once you get the hang of sHM it's not so bad - a great tool in fact. -Nuc |
|
August 26, 2014, 09:54 |
|
#16 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
Well, after five more error messages I'm stagnant again. When sHM was writing mesh on folder 2 it crashed with a fatal IO error, then I erased the sHM folders and I run it again. It crashed again with the same kind of error but now writing mesh in the folder 1. Then I erased also the blockMesh files and when i tried to blocKmesh again it crashed with the same error too, exactly this:
--> FOAM FATAL IO ERROR: error in IOstream "/home/caelinux/Desktop/Test/constant/polyMesh/points" for operation Ostream& operator<<(Ostream&, const Scalar&) file: /home/caelinux/Desktop/Test/constant/polyMesh/points at line 5621. From function IOstream::check(const char*) const in file db/IOstreams/IOstreams/IOstream.C at line 99. FOAM exiting I don't know why it happens, I modified the refinement box and the max local and global cells due to I was running out of memory but I guess this is not the reason, it seems like a type variable error. I searched in the forum but some post weren't answered and others I didn't understand it. Thanks for your time. |
|
October 4, 2014, 14:22 |
|
#17 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128 |
Greetings to all!
@H25E: I've arrived a late to the discussion, but from your latest description, I would say that you're running out of disk space, which is why it's stopping earlier and earlier in the meshing process. Run the following command, to check if you have enough disk space in the folder you're working on: Code:
df -h $PWD Bruno
__________________
|
|
October 7, 2014, 17:16 |
|
#18 |
New Member
H25E
Join Date: Jul 2014
Posts: 27
Rep Power: 12 |
Finally I reinstalled linux some weeks ago, so maybe it was the reason. Thanks anyway for your answer.
|
|
Tags |
mesh error, openfoam, snappyhexmesh |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[snappyHexMesh] Running snappyHexMesh in parallel - optimizing | peterhess | OpenFOAM Meshing & Mesh Conversion | 2 | January 3, 2018 03:54 |
[snappyHexMesh] snappyHexMesh large parallel case crash | C-L | OpenFOAM Meshing & Mesh Conversion | 0 | August 15, 2017 10:40 |
[snappyHexMesh] Tutorial crashes: snappyHexMesh floating point exception. | jasv | OpenFOAM Meshing & Mesh Conversion | 4 | May 10, 2016 03:55 |
[snappyHexMesh] SnappyHexMesh crash (floating point exception while snappying) | Frank_uk | OpenFOAM Meshing & Mesh Conversion | 1 | January 9, 2016 07:19 |
[snappyHexMesh] stitchMesh and snappyHexMesh | gdbaldw | OpenFOAM Meshing & Mesh Conversion | 0 | December 23, 2009 03:09 |