CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

snappyHexMesh add-layers issues, warped cells

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

Like Tree3Likes
  • 1 Post By heling
  • 1 Post By chegdan
  • 1 Post By chegdan

Reply
 
LinkBack Thread Tools Display Modes
Old   July 1, 2013, 14:33
Unhappy snappyHexMesh add-layers issues, warped cells
  #1
New Member
 
Natan Zawadzki
Join Date: Jun 2013
Posts: 2
Rep Power: 0
heling is on a distinguished road
Dear cfd-users,

I'm trying to create a mesh inside a 3d-channel with a hill on the bottom. All channel walls in except of the lower wall I created with BlockMesh. The bottom geometry including the bump I put in the constant/triSurface directory as a .stl file.

Although it seems to be a relatively simple geometry I get some considerable issues during the layers adding. The boundary layers on the bump (but solely on the bump, see attached pict.) are highly warped, at many places overgrown itself or even don't exist. In all probability the problem is causes by inadequately quality of the bump surface.

First I thought I should in the snappyHexMeshDict file just increase the level of surface refinement and the number of smoothing iterations before finding a correspondence to the surface. In except of computation time nothing changes xD

My 2nd presumption was that the bad surface quality is caused by incorrect facet normals orientation. I checked the normals in the .stl file with a self-made matlab code and yes, a lot of normals wasn't vertical on the triangular faces, as should be. Then I wrote a code to reorient the normals but the issue still occur... Below I attached a few pictures showing my problem, an the complete foam run directory with all dictionaries.

I will be very grateful for some helpful advices.


Attachment description:

pict0: whole channel geometry created with blockMesh and sHM, without edges

cut1: x normal, cut in the middle of the bump: as You can recognize in the middle of the hill the surface is relatively smooth, then on the sides strongly warped...

cut2: z normal

cut3: z normal & x normal: as You can easily recognize on the ragged sides of the bump no layers have been added...

Download link for run directory:
https://docs.google.com/file/d/0B-av...it?usp=sharing
Attached Images
File Type: jpg pict0.jpg (9.9 KB, 146 views)
File Type: jpg cut1.jpg (88.2 KB, 201 views)
File Type: jpg cut2.jpg (69.6 KB, 205 views)
File Type: jpg cut3.jpg (78.8 KB, 196 views)
heling is offline   Reply With Quote

Old   July 2, 2013, 11:14
Default
  #2
Senior Member
 
Mihai Pruna
Join Date: Apr 2010
Location: Boston
Posts: 190
Blog Entries: 1
Rep Power: 7
mihaipruna is on a distinguished road
looks like your mesh isn't snapped?
can't tell.
check if it SHM says "did not successfully snap mesh".
If the mesh is not snapped, I recommend you disable layers and focus on the snapping problem first.
mihaipruna is offline   Reply With Quote

Old   July 2, 2013, 13:25
Default
  #3
New Member
 
Natan Zawadzki
Join Date: Jun 2013
Posts: 2
Rep Power: 0
heling is on a distinguished road
I've got it :-)

the mesh looks like snapped in just one direction (because of the smooth string in the middle of the bump) In the blockMeshDict I had set the frondAndBack patch as "empty". As soon as I set them as "patches", everything worked out. Could be that the snapping direction depend on the patch definition in the BlockMeshDict? Why?


@mihaipruna Thanks for the reply!
mihaipruna likes this.
heling is offline   Reply With Quote

Old   July 2, 2013, 13:30
Default
  #4
Senior Member
 
Mihai Pruna
Join Date: Apr 2010
Location: Boston
Posts: 190
Blog Entries: 1
Rep Power: 7
mihaipruna is on a distinguished road
I've used empty patches to make "2D" flows. I think if you set them as empty SHM won't bother in that direction.
mihaipruna is offline   Reply With Quote

Old   July 2, 2013, 18:30
Default
  #5
Senior Member
 
chegdan's Avatar
 
Daniel P. Combest
Join Date: Mar 2009
Location: St. Louis, USA
Posts: 535
Rep Power: 18
chegdan will become famous soon enough
snappyHexMesh has some issues when it tries to add layers on a surface that isn't aligned with the coordinate plane sometimes. i suggest
  • Use relative layer height instead of absolute (if you were using absolute)
  • Use distance refinement to produce unifromly refined cells near the surface to make layer addition easier
  • Add smaller layers first since those are easier to add and less likely to be collapsed due to bad quality.

Hope that helps.
s.m likes this.
__________________
Dan

Find me on twitter @dancombest and LinkedIn
chegdan is offline   Reply With Quote

Old   August 19, 2013, 09:34
Default
  #6
s.m
Senior Member
 
saeideh mohamadi
Join Date: Aug 2012
Posts: 229
Rep Power: 5
s.m is on a distinguished road
Quote:
Originally Posted by chegdan View Post
snappyHexMesh has some issues when it tries to add layers on a surface that isn't aligned with the coordinate plane sometimes. i suggest
  • Use relative layer height instead of absolute (if you were using absolute)
  • Use distance refinement to produce unifromly refined cells near the surface to make layer addition easier
  • Add smaller layers first since those are easier to add and less likely to be collapsed due to bad quality.

Hope that helps.
Dear daniel,
How could we use distance refinement to produce unifromly refined cells near the surface to make layer addition easier?

would you explain it more..
Thank you very much
s.m is offline   Reply With Quote

Old   August 19, 2013, 09:47
Default
  #7
Senior Member
 
chegdan's Avatar
 
Daniel P. Combest
Join Date: Mar 2009
Location: St. Louis, USA
Posts: 535
Rep Power: 18
chegdan will become famous soon enough
An example of what I was referring to is in a presentation from the last workshop located here. Look at slides 67-69 and maybe a few before to explain what i was trying to achieve. An example of this is also provided here in section 5.4.5, where

Code:
refinementRegions 
  { 
      box1x1x1 
      { 
          mode inside; 
          levels ((1.0 4));         // refinement level 4 (1.0 entry ignored) 
      } 
   
      sphere.stl 
      {                             // refinement level 5 within 1.0 m 
          mode distance;            // refinement level 3 within 2.0 m 
          levels ((1.0 5) (2.0 3)); // levels must be ordered nearest first 
      } 
  }
The idea is that if the layer height is based on relative size near the surface, if you make the spacing uniform in that area then it should create some uniformly sized layer cells. The one thing is that distance refinement is uniform over an entire STL file. If you have multiple STL files e.g. one for each patch, then you have much more freedom to do distance refinement on a per-patch basis rather than a whole geometry.
s.m likes this.
__________________
Dan

Find me on twitter @dancombest and LinkedIn
chegdan is offline   Reply With Quote

Old   August 19, 2013, 09:54
Default
  #8
s.m
Senior Member
 
saeideh mohamadi
Join Date: Aug 2012
Posts: 229
Rep Power: 5
s.m is on a distinguished road
Quote:
Originally Posted by chegdan View Post
An example of what I was referring to is in a presentation from the last workshop located here. Look at slides 67-69 and maybe a few before to explain what i was trying to achieve. An example of this is also provided here in section 5.4.5, where

Code:
refinementRegions 
  { 
      box1x1x1 
      { 
          mode inside; 
          levels ((1.0 4));         // refinement level 4 (1.0 entry ignored) 
      } 
   
      sphere.stl 
      {                             // refinement level 5 within 1.0 m 
          mode distance;            // refinement level 3 within 2.0 m 
          levels ((1.0 5) (2.0 3)); // levels must be ordered nearest first 
      } 
  }
The idea is that if the layer height is based on relative size near the surface, if you make the spacing uniform in that area then it should create some uniformly sized layer cells. The one thing is that distance refinement is uniform over an entire STL file. If you have multiple STL files e.g. one for each patch, then you have much more freedom to do distance refinement on a per-patch basis rather than a whole geometry.
Thank you, i study it now.
s.m is offline   Reply With Quote

Old   August 19, 2013, 12:16
Default
  #9
Member
 
Miro
Join Date: Jan 2013
Location: Europe
Posts: 51
Rep Power: 4
miro2000 is on a distinguished road
One could also disable relative layer size. In that case, refinement level doesn't have to be uniform on the surface.

- miro
miro2000 is offline   Reply With Quote

Old   August 19, 2013, 13:01
Default
  #10
Senior Member
 
chegdan's Avatar
 
Daniel P. Combest
Join Date: Mar 2009
Location: St. Louis, USA
Posts: 535
Rep Power: 18
chegdan will become famous soon enough
@ Miro: This is true but then you would have to know the physical size of the cells you would like as your boundary layer. I myself prefer to use relative size since it is a little easier to add layer cells...but this is a good point you've made and definitely an option
__________________
Dan

Find me on twitter @dancombest and LinkedIn
chegdan is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
snappyHexMesh and concave cells GerhardHolzinger OpenFOAM Native Meshers: snappyHexMesh and Others 2 December 16, 2013 10:43
snappyHexMesh in parallel - FOAM Fatal IO Error mturcios777 OpenFOAM Running, Solving & CFD 4 August 10, 2012 19:18
[ICEM] error analysis despaired student ANSYS Meshing & Geometry 7 June 27, 2012 11:57
SnappyHexMeshDict fabrizio OpenFOAM Mesh Utilities 25 October 14, 2011 07:00
no boundary layers using snappyHexMesh thorsten OpenFOAM Native Meshers: snappyHexMesh and Others 1 October 22, 2009 06:01


All times are GMT -4. The time now is 14:27.