[Jaworski.Mike]

Hi all. I'm trying to develop a work flow for generating STL files in Gmsh for use with sHM with chtMultiRegionFoam. I am having a problem in that I seem to often be generating an error which is preventing sHM from working.

--> FOAM Warning :
From function autoSnapDriver::calcNearestSurface(..)
in file autoHexMesh/autoHexMeshDriver/autoSnapDriver.C at line 914
For point:22778 coordinate-0.1723479 -0.1434135 0.01919383) did not find any surface within:0.00375 meter.

^ This comes up a lot in the log file. When I googled for the error, I found nothing.

What I'm trying to do is place a cylinder in a box. So I have a separate STL for the cylinder ("heater") and one for the box with the cylinder removed ("bulkFluid"). I was trying to keep the base files as close to the tutorial in snappyChtMultiRegionFoam as possible.

sHM runs to completion, but there's a message that:
"Did not succesfully snap mesh. Giving up."

It then writes some ugly meshes in the 0.003 time folder.

I was able to get the cylinder to make a nice mesh when I wasn't trying to keep multiple regions for working with chtMultiRegionFoam. Now, however, it seems to be having a problem. I would have thought this was simple enough to almost exactly copying the tutorial would have been ok, apparently not. But, I may just be missing something obvious that someone else has found.

Any help is greatly appreciated.

Cheers,
Mike

PS blockMeshDict and snappyHexMeshDict attached. STLs are apparently too large.

[Jaworski.Mike]

A small update and fixed up a small file-server to put larger files up. Here is an image of the mesh showing the cellLevel field:
http://www.pppl.gov/~mjaworsk/OpenFOAM/newSnappyProblems/snap_file_mesh_1.png

It doesn't seem to be capturing all the surfaces to make them the same cellLevel before snapping. So, whereas this should be a cylinder, there are four edges and that's it.

I re-jiggered the case to just separate out the two stl files and see what's happening. In this instance, it does snap correctly however, it still is not refining the surface correctly.
http://www.pppl.gov/~mjaworsk/OpenFOAM/newSnappyProblems/snap_file_mesh_2.png

It does this either with the bulkFluid_v1.stl or heater_v1.stl files and associated *.eMesh files.
more files here: http://www.pppl.gov/~mjaworsk/OpenFOAM/newSnappyProblems/

I did notice that the stl file didn't quite make a the mesh I wanted it to. Could this be a case a bad stl?

Many thanks for any and all assistance.
-Mike

[fly_low_hit_hard]

I'm having quite similar problem, snappy doesn't snap the cells vertexes to the contour of the hole I want to create into the 2-D dominion... it once did snap the same geometry but then suddently and apparently with no reason it didn't anymore... help please

[Irish09]

Hello Mike and Flylow,

I've taken a quick look at your problems and I can attempt some suggestions.

First Mike, I noticed that you have addlayers set to false at the beginning of your SHMdict file and had some layers defined to be added. You may have just set this to false to enable faster running until the snapping was resolved, but wanted to make sure you were aware that you were not actually adding any layers.

Now these suggestions may apply to both of you:

Secondly, I would suggest looking at the .eMesh files you output to make sure they are actually trying to capture the correct features of the geometry. If you write the command like this:

surfaceFeatureExtract -includedAngle 180 -writeObj  constant/triSurface/SprayA210675doublesmoothascii.stl  outputfile

Then you output several .obj files you can open in paraview. I believe the one that gets labeled as internal edges is the one I use to check the refinement.

Thirdly, I would make that the names of the regions you specify in refinementSurfaces match what SHM calls them. Currently you have heater and bulkFluid as you named them in the geometry section. But from my experience SHM adds some text to the end of if.

One example I am currently working on names the geometry inputs like this (listed in the SHM output):

Patch   Type    Region
-----   ----    ------
wall:

5       wall    wall_patch0

inlet:

6       wall    inlet_patch0

outlet:

7       wall    outlet_patch0

needle:

8       wall    needle_patch0

From this input (SHMdict file):

geometry
{
    SprayA_210675_meanDiaZ_wall.stl
    {
        type triSurfaceMesh;
        name wall;
    }
    SprayA_210675_meanDiaZ_inlet.stl
    {
        type triSurfaceMesh;
        name inlet;
    }
    SprayA_210675_meanDiaZ_outlet.stl
    {
        type triSurfaceMesh;
        name outlet;
    }
    SprayA_210675_meanDiaZ_needle.stl
    {
        type triSurfaceMesh;
        name needle;
    }
};

You can see that an underscore and patch0 is added to all of the names.

So I usually write my refinement surfaces as:

    refinementSurfaces
    {
      "wall_*"
      {
          // Surface-wise min and max refinement level
          level (5 6);
      }
      "outlet_*"
      {
          // Surface-wise min and max refinement level
          level (5 6);
      }
      "inlet_*"
      {
          // Surface-wise min and max refinement level
          level (2 3);
      }
      "needle_*"
      {
          // Surface-wise min and max refinement level
          level (2 3);
      }
    }
    }

[vonboett]

"did not find any surface within:0.00375 meter" means that within snapControls, the tolerance is set so small that for several points at the boundary of your unsnapped mesh no point to snap lies within 0.00375 m. This 0.00375 m arises from tolerance * local maximum edge length of your mesh.