[Stefanie.S.W.]

Hello,



i would like to use snappyHexMesh with an stl-file from Solid Works.
My BlockMesh is large enough for my geometry and should be fine enough to catch all lines of my geometry. Still snappyHexMesh gets stuck and does not continue with the process.

I do not run the process parallel.

• I started with "blockMesh", which worked fine
• "surfaceFeatureExtract" returned multible error messages - I am not sure if I need to run this at all when using a stl-geometry (?) - Error messages are attached
• SnappyHexMesh stops after the following:
  
  Create time
  Create mesh for time = 0
  Read mesh in = 0.01 s
  Overall mesh bounding box : (0 0 0) (900 950 900)
  Relative tolerance : 1e-06
  Absolute matching distance : 0.00158824

Why does it not work?







Reading surfaceFeatureExtractDict

Surface : "WandEinlauf.stl"


Feature line extraction is only valid on closed manifold surfaces.
#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 ? in "/lib64/libc.so.6"
#3 yyFlexLexer::yy_get_previous_state() in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libtriSurface.so"
#4 STLLexer::lex() in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libtriSurface.so"
#5 Foam::triSurface::readSTLASCII(Foam::fileName const&) in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libtriSurface.so"
#6 Foam::triSurface::readSTL(Foam::fileName const&) in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libtriSurface.so"
#7 Foam::triSurface::read(Foam::fileName const&, Foam::word const&, bool) in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libtriSurface.so"
#8 Foam::triSurface::triSurface(Foam::fileName const&) in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libtriSurface.so"
#9 ? in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/bin/surfaceFeatureExtract"
#10 __libc_start_main in "/lib64/libc.so.6"
#11 ? in "/opt/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/bin/surfaceFeatureExtract"
Segmentation fault (core dumped)

[ssa_cfd]

try saving the stl as ascii version and run surfacefeatureExtract.. then run snappy.

[RobertHB]

Originally Posted by Stefanie.S.W.

"surfaceFeatureExtract" returned multible error messages - I am not sure if I need to run this at all when using a stl-geometry (?)

Whether or not you need to use surfaceFeatureExtract depends on the following lines in your snappyHexMeshDict:

snapControls
{
    ...
    // Feature snapping
        ...
        //- Detect (geometric) features by sampling the surface
        implicitFeatureSnap true;

        //- Use castellatedMeshControls::features
        explicitFeatureSnap false;

        //- Detect features between multiple surfaces
        //  (only for explicitFeatureSnap, default = false)
        multiRegionFeatureSnap true;
}

When using implicitFeatureSnap you don't need surfaceFeatureExtract, but when using explicitFeatureSnap you do.

[Stefanie.S.W.]

Thank you a lot for helping and explaining ssa_cfd and RobertHB!
I feel like understanding the dictionary a little bit more now.

My first mistake was that my geometry was a lot larger than I thought, because OpenFoam writes every length in [m].

Unfortunately SHM does not return an error message in this case. Maybe it just kept on trying to snap the block mesh to a 1000 times larger object.

I saved the geometry as .stl in ASCII and converted mm to m. Now it works :-)

[RobertHB]

Originally Posted by Stefanie.S.W.

Thank you a lot for helping and explaining ssa_cfd and RobertHB!
I feel like understanding the dictionary a little bit more now.

There are two websites [1] and [2] who give a detailed explanation of the snappyHexMeshDict.
As for your .stl not matching your blockMesh, you can always open your blockMesh in paraview and load the .stl to see if the two overlap.

[Stefanie.S.W.]

thanks to your help I could reduce the no of incorrectly orientated face pyramids to 10 and the no of highly skew faces to 2 - still I think those errors hinder the computation.



Additionally I could fix the incorrectly orientated face pyramids by using higher refinement in SnappyHexMesh and using "xxx.eMesh" for the features sub dictionary.



Now a new error occurred (besides the two skew faces):



the bottom wedge remained after increasing the refinement. Before SnappyHexMesh removed the wedge. I hope you can see it on the picture attached


Is there a way to remove the wedge without changing the blockMesh to a sloped geometry?

Also do you know which parameter can help with fixing the skew faces?
Is it a parameter in the snappyHexMeshDict? I attached the dict below.

Thank you for your help!





Hopefully the quotation of the Mesh-Quality-Code works.....

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.4.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.4.0-dcea1e13ff76
Exec : checkMesh
Date : Nov 21 2018
Time : 15:06:08
Host : "intze.iww.rwth-aachen.de"
PID : 20386
Case : /work/Stefanie/50Hertz/Modell15/interFoam/laminarSolW2
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 4457957
faces: 10529001
internal faces: 9332477
cells: 3100949
faces per cell: 6.40497
boundary patches: 14
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 2278173
prisms: 108586
wedges: 9699
pyramids: 0
tet wedges: 15165
tetrahedra: 1964
polyhedra: 687362
Breakdown of polyhedra by number of faces:
faces number of cells
4 1168
5 27141
6 193922
7 93496
8 35477
9 266285
10 2205
11 323
12 52615
13 23
14 95
15 12527
16 1
17 7
18 2077

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
frontAndBack 229422 271735 ok (non-closed singly connected)
inlet 5987 7026 ok (non-closed singly connected)
outlet 135599 150478 ok (non-closed singly connected)
lowerWall 23587 25656 ok (non-closed singly connected)
upperWall 4190 4687 ok (non-closed singly connected)
WandEinlauf 117472 134483 ok (non-closed singly connected)
WandAblauf 265711 305642 ok (non-closed singly connected)
BodenplatteA 152530 190758 ok (non-closed singly connected)
BodenplatteB 49457 56658 ok (non-closed singly connected)
BodenplatteC 36322 43270 ok (non-closed singly connected)
TrennwandA 60094 73266 ok (non-closed singly connected)
TrennwandB 52486 62256 ok (non-closed singly connected)
TrennwandC 1976 2269 ok (non-closed singly connected)
TrennwandD 61691 69721 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0.0297 0 0.3) (2.73 0.9 0.9)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (3.10236e-15 3.11251e-16 -6.64025e-17) OK.
Max cell openness = 1.33631e-15 OK.
Max aspect ratio = 145.065 OK.
Minimum face area = 1.71221e-09. Maximum face area = 0.00106847. Face area magnitudes OK.
Min volume = 7.47675e-13. Max volume = 1.22645e-05. Total volume = 1.37763. Cell volumes OK.
Mesh non-orthogonality Max: 67.2158 average: 16.5804
Non-orthogonality check OK.
Face pyramids OK.
***Max skewness = 7.59641, 2 highly skew faces detected which may impair the quality of the results
<<Writing 2 skew faces to set skewFaces
Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End

[RobertHB]

Originally Posted by Stefanie.S.W.

Is there a way to remove the wedge without changing the blockMesh to a sloped geometry?

I'm unsure of what is going wrong here. I can think of two things:
1) You are using multiple .stl files to construct one geometry. In this case sHM might struggle combining the parts into one and thus also includes the blockMesh.


2) You are using one geometry, which you are trying to mesh from the inside. sHM not discarding the outer blockMesh can be a sign of your geometry not being closed or "watertight". sHM uses all cells it can "see" from the pointInMesh. If you have a hole in your mesh, sHM can see the outer cells and thus includes the outside aswell.

Hopefully the quotation of the Mesh-Quality-Code works....

Two skewed faces? I'm running simulations with a mesh much worse. Don't worry. One failed checkMesh, and than in low numbers, is rarely any trouble.