CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[snappyHexMesh] snappyHexMesh failing to snap ("did not find surface within...")

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree11Likes
  • 2 Post By Irish09
  • 9 Post By vonboett

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 10, 2012, 03:56
Default snappyHexMesh failing to snap ("did not find surface within...")
  #1
New Member
 
Mike Jaworski
Join Date: Jul 2012
Location: New Jersey
Posts: 6
Rep Power: 13
Jaworski.Mike is on a distinguished road
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.
Attached Files
File Type: txt blockMeshDict.txt (1.7 KB, 38 views)
File Type: txt snappyHexMeshDict.txt (10.5 KB, 108 views)

Last edited by Jaworski.Mike; July 10, 2012 at 04:00. Reason: Attachments didn't attach.
Jaworski.Mike is offline   Reply With Quote

Old   July 10, 2012, 12:47
Default
  #2
New Member
 
Mike Jaworski
Join Date: Jul 2012
Location: New Jersey
Posts: 6
Rep Power: 13
Jaworski.Mike is on a distinguished road
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
Jaworski.Mike is offline   Reply With Quote

Old   August 4, 2012, 08:33
Default
  #3
New Member
 
Flylow Hithard
Join Date: Jul 2012
Posts: 2
Rep Power: 0
fly_low_hit_hard is on a distinguished road
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
Attached Images
File Type: jpg Schermata del 2012-08-04 13:22:00.jpg (40.9 KB, 500 views)
Attached Files
File Type: txt snappyHexMeshDict .txt (10.4 KB, 45 views)

Last edited by fly_low_hit_hard; August 4, 2012 at 13:31.
fly_low_hit_hard is offline   Reply With Quote

Old   August 5, 2012, 13:17
Default Suggestions
  #4
New Member
 
Tom
Join Date: Nov 2011
Location: Atlanta, Ga
Posts: 21
Rep Power: 14
Irish09 is on a distinguished road
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:

Code:
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):
Code:
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):

Code:
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:

Code:
    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);
      }
    }
    }
holodeck10 and saket411 like this.
Irish09 is offline   Reply With Quote

Old   January 30, 2013, 04:40
Default
  #5
Senior Member
 
Albrecht vBoetticher
Join Date: Aug 2010
Location: Zürich, Swizerland
Posts: 237
Rep Power: 16
vonboett is on a distinguished road
"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.
Tobi, yanxiang, jbernardo and 6 others like this.
vonboett is offline   Reply With Quote

Old   May 27, 2013, 09:41
Default
  #6
Member
 
Join Date: Oct 2012
Posts: 47
Rep Power: 13
sh.d is on a distinguished road
hi
i want creat 2_D mesh a round airfoil whit snappyhexmesh.but not snap the surface of airfoil.please can you help me?
sh.d is offline   Reply With Quote

Old   May 27, 2013, 09:43
Default
  #7
Member
 
Join Date: Oct 2012
Posts: 47
Rep Power: 13
sh.d is on a distinguished road
folloing is the my test case
Attached Files
File Type: zip sanappy.zip (4.0 KB, 70 views)
sh.d is offline   Reply With Quote

Old   December 2, 2019, 21:13
Default
  #8
New Member
 
Ahmet sen
Join Date: Dec 2019
Posts: 1
Rep Power: 0
ahmetsen is on a distinguished road
Quote:
Originally Posted by vonboett View Post
"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.
I don't know exactly how to increase it .openfo but i just started. Can you help me?
ahmetsen is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[snappyHexMesh] Surface triangulation using snappyHexMesh shaileshbg OpenFOAM Meshing & Mesh Conversion 4 October 17, 2019 05:42
[snappyHexMesh] snappyHexMesh doesnt snap staustrahltriebwerk OpenFOAM Meshing & Mesh Conversion 47 March 18, 2018 15:19
[snappyHexMesh] snappyHexMesh inclinced surface snapping problem Swift OpenFOAM Meshing & Mesh Conversion 19 January 18, 2017 05:42
[snappyHexMesh] problem with snappyHexMesh kanes OpenFOAM Meshing & Mesh Conversion 10 January 26, 2016 07:11
[snappyHexMesh] Problem with snappyhexMesh: modelling a pore chamber and pore throat model Saideep OpenFOAM Meshing & Mesh Conversion 5 May 10, 2015 15:46


All times are GMT -4. The time now is 08:42.