[Bob Tipton]

I've had this working in the past, but now I cannot get snappyHexMesh to snap to anything.

I was able to get very smoothly snapped results before, but now I get nothing but blocks. I've checked obvious things like is the snapping phase on/off, upped the tolerance as high as 10 (which is lunacy) just to see if it has an effect - it didn't.

I still get nothing but blocks when I need something smooth.


Updated: As far as I can tell, I'm doing everything correctly - obviously I am not.
I have updated to OpenFOAM v8
I have removed the .emesh files

I have run
blockMesh
surfaceFeatures
snappyHexMesh

Update 2: This looks like a bug. Over repeated attempts, there were one or two where the snapping worked correctly. When I made small modifications (such as increasing a division level) it went back to castellated. This seems highly unlikely because it would seem to be extremely common and others would have found it. Unless there is something very specific about this geometry.


The dictionary used to create the image follows. blockMeshDict and surfaceFeaturesDict are included for completeness.

FoamFile
{
version 2.0;
class dictionary;
format ascii;
location "system";
object snappyHexMeshDict;
}
castellatedMesh true;
snap true;
addLayers true;
geometry
{
Model.stl
{
type triSurfaceMesh;
simflowType stl;
name Model;
includedAngle 120.0;
}
Refine1.stl
{
type triSurfaceMesh;
simflowType stl;
name Refine1;
includedAngle 120.0;
}
Refine2.stl
{
type triSurfaceMesh;
simflowType stl;
name Refine2;
includedAngle 120.0;
}
}
castellatedMeshControls
{
locationInMesh (10 10.0 10.0);
refinementSurfaces
{
Model
{
level ( 5 5 );
patchInfo
{
type wall;
}
}
}
refinementRegions
{
Refine1
{
mode inside;
levels ((1.0E30 2));
}
Refine2
{
mode inside;
levels ((1.0E30 1));
}
}
limitRegions
{
}
features
(
);
maxLocalCells 500000;
maxGlobalCells 4000000;
nCellsBetweenLevels 4;
maxLoadUnbalance 0.1;
minRefinementCells 10;
resolveFeatureAngle 15.0;
allowFreeStandingZoneFaces true;
}
snapControls
{
tolerance 1.0;
nSmoothPatch 3;
nSolveIter 500;
nRelaxIter 5;
nFeatureSnapIter 10;
implicitFeatureSnap true;
explicitFeatureSnap true;
multiRegionFeatureSnap true;
nFaceSplitInterval 5;
}
addLayersControls
{
layers
{
Model
{
nSurfaceLayers 5;
expansionRatio 1.25;
firstLayerThickness 0.2;
}
Model_patch0
{
nSurfaceLayers 5;
expansionRatio 1.25;
firstLayerThickness 0.2;
}
}
relativeSizes true;
minThickness 0.001;
firstLayerThickness 1.0E-4;
expansionRatio 1.25;
nGrow 0;
featureAngle 180.0;
maxFaceThicknessRatio 0.5;
nSmoothSurfaceNormals 5;
nSmoothThickness 10;
minMedialAxisAngle 90.0;
maxThicknessToMedialRatio 0.5;
nMedialAxisIter 100;
nSmoothNormals 3;
slipFeatureAngle 30.0;
nRelaxIter 5;
nBufferCellsNoExtrude 0;
nLayerIter 50;
nRelaxedIter 20;
detectExtrusionIsland true;
}
meshQualityControls
{
maxNonOrtho 65.0;
maxBoundarySkewness 20.0;
maxInternalSkewness 4.0;
maxConcave 80.0;
minVol 1.0E-14;
minTetQuality 1.0E-20;
minArea -1.0;
minTwist 0.02;
minTriangleTwist -1.0;
minDeterminant 0.01;
minFaceWeight 0.05;
minVolRatio 0.01;
minVolCollapseRatio 0.1;
nSmoothScale 4;
errorReduction 0.75;
relaxed
{
maxNonOrtho 75.0;
}
}
mergeTolerance 1.0E-6;
debug 0;


*************************************************


FoamFile
{
version 2.0;
class dictionary;
format ascii;
location "system";
object blockMeshDict;
}
convertToMeters 1;
edges
(
);
vertices
(
(-25.0 0.0 0.0)
(75.0 0.0 0.0)
(75.0 50.0 0.0)
(-25.0 50.0 0.0)
(-25.0 0.0 50.0)
(75.0 0.0 50.0)
(75.0 50.0 50.0)
(-25.0 50.0 50.0)
);
blocks
(
hex (0 1 2 3 4 5 6 7) (50 25 25) simpleGrading (
(
(20 10 .125)
(15 30 1)
(65 10 8)
)
(
(5 10 1)
(45 15 8)
)
(
(5 10 1)
(45 15 8)
)
)
);
boundary
(
boundaries
{
type patch;
faces
(
(0 4 7 3)
(2 6 5 1)
(3 7 6 2)
(4 5 6 7)
);
}

symmetry
{
type symmetry;
faces
(
(1 5 4 0)
(0 3 2 1)
);
}

);

*--------------------------------*- C++ -*----------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 8
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object surfaceFeaturesDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

surfaces
(
"Model.stl"
"Refine1.stl"
"Refine2.stl"
);

includedAngle 150;

subsetFeatures
{
nonManifoldEdges yes;
openEdges yes;
}

trimFeatures
{
minElem 0;
minLen 0;
}

writeObj no;

****************************************

I have been working on finding a way to efficiently solve high drag/high turbulence cases. They require surprisingly large analysis volumes, thus the complex grading and refinement regions for such a small part. This is just to calibrate the approach against a solid hemisphere.

[stinkfist]

Hi,
does SHM print all the three timestep? It clearly seems to stop at castellatedMesh

[Bob Tipton]

Yes,

The log is also showing the smoothing convergence and quality calculations that are output during the snapping phase. However, the quality is always perfect which corresponds with a perfectly Cartesian mesh.

Turning snap off also eliminates this output. Turning it back on brings it back.

I've filed a bug.
I'm in the process of setting up a Linux dual boot on an external drive in case the WSL environment is causing this. It will also allow me to build from source and debug what's happening.

[AtoHM]

I have not read everything but in my experience if it does not snap at all, it is almost always related to the blockMesh not being appropriate. Have you checked that the blockMesh fully contains all your geometry in it? Make the blockMesh a little bigger in all directions to allow snappy to work correctly. Hope this helps.


EDIT: dont do this: locationInMesh (10 10.0 10.0);
The locationInMesh must never be located at a possible node location (even after refinement!), use some float numbers like 10.0121 instead which reduces the propability of snappy placing a node there.

[Bob Tipton]

I've experimented with that also.


locationInMesh (2.000001 2.000001 2.000001); // Offset from (0 0 0) to avoid
// coinciding with face or edge



The above produces the same result.



The documentation is a bit vague. Must the point not touch a model face or mesh face or both? I've assumed it must not touch a model vertex, edge or face. In which case that point is meters away from the model.


The original image doesn't show the entire volume. See the new image. It's well inside.

It also fails to explain how one run out of ~20 suddenly worked and when I increased the division level it failed again. When I put the division level back, it failed also.

I don't see how, but it's possible that the Win 10/WSL environment may be the cause.

[AtoHM]

From what I understand it shouldn't touch any mesh entities and must lay within a resulting cell. The position with respect to geometry provides what part of the mesh to keep. No idea what happens if it coincides with geometry, I guess it would behave unexpectedly. I wouldn't try it.


The picture you show is just a 4th of the whole thing right?

[Bob Tipton]

Yes. There are two symmetry planes.

[Bob Tipton]

I should add that I've been successfully running cases using SymFlow (based on openFoam) as the mesher for a few months.

But SymFlow doesn't support the more advanced grading, edge refinement and other features which I need to properly analyze my cases.

Without the larger cases my analyses are invalidated or diverge often. I need to get SHM working reliably. I've been trying to get pure SHM working since April or May, been on various boards, watched videos etc.

The instance where it suddenly worked once or twice and then stopped working again looks like a non-deterministic problem/bug.

I've made several tries with a different seed point, carefully selected to avoid cell boundaries and it made no difference. I have seen that when the point is badly placed it causes an error message and an abort of SHM. I'm not getting that.

[AtoHM]

Ok I think I really get what you're trying to do right now. As I said, the blockMesh should be a bit bigger than the geometry for snappy to work correctly. Now with your symmetry planes, I wonder if your blockMesh also covers only a fourth of the geometry? Maybe you can zoom in a bit, so we can see how big the geometry is and where you define the blockMesh to be?

Maybe you can fully revert your approach to make it work: Instead of creating a blockMesh and cutting out only the geometry, you can invert your geometry, create a slightly bigger blockMesh and keep everything inside. I assume you can create the symmetry patches by createPatch after running sHM. I hope you understand what I mean .. a bit hard to describe. However thats the usual way I create my meshes and it works very reliably.

[Bob Tipton]

I see where you're going with that.

I see a more economical way of getting there.

If I were going to make a career out of using OpenFOAM I would invest the time, but this is a large workaround for a one time job I'm trying to accomplish.

I can get SymFlow to do what I need if I use enough refinement regions. However, it overwrites dicts with rev7 versions. There also seem to be some significant changes in dict layouts between 7 and 8.

If I revert to using Rev 7 and SymFlow I'll be done before I get your approach working.

My project is drag MAXIMIZATION. I've been making some pretty interesting discoveries, but each time I increase the drag on a model it causes divergence due to the large disturbance in the flow. This drives the analysis volume up and that causes me to seek new meshing strategies.

I'm also self funded with near zero budget - so the cloud services aren't available to me. Neither are high tools. Oh for access to a high end Lattice-Boltzmann app like EXA.

So, I've been making optimal use of symetries, grading, region refinement etc to get these cases to run on an 8 GB Windows box. The last straw was when I finally found an example of how to get good agreement with reference shapes like the hemisphere and it required a 40x analysis volume. When I did that, I got .7% agreement with a thin square plate. When I tried to correllate with the hemisphere - no luck.

I've led a dual career as a user/author of high end CAD/CAE/Meshing/Design apps. Given a dedicated 6 to 9 months I can write a better, faster, more reliable mesher.

I also have two degrees in aerospace from GA Tech with my graduate focus in aeroelasticity.

I've read online that there is a need for such a tool and my experience with this proves that out. IMO most of the GUI tools are decades behind current tech.

For example.
There is no need for a model mesh to intersect a cell edge. Using the proper spatial search it's possible to find a cell containing model triangles with no crossings and subdivide it until there are crossings.

I have a shopping list of issues I've discovered so far and I've spent 3/4 of my hours trying to achieve the mesh I know I need instead of focussing on the fluid dynamics.

Do you see a demand for an improved meshing tool?

[AtoHM]

I highly doubt my approach takes alot of time, inverting the geometry is like 1 boolean operation in a standard CAD tool. Increasing the blockMesh is like increasing a few values in the snappy dictionary. Done.


When you apply a free mesher, you just cannot expect that it works perfectly out of the box for each case. My opinion of snappy is quite good, as long as you don't need perfect boundary layers.