[heling]

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

[mihaipruna]

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.

[heling]

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]

I've used empty patches to make "2D" flows. I think if you set them as empty SHM won't bother in that direction.

[chegdan]

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]

Originally Posted by chegdan

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

[chegdan]

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

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]

Originally Posted by chegdan

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

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.

[miro2000]

One could also disable relative layer size. In that case, refinement level doesn't have to be uniform on the surface.

- miro

[chegdan]

@ 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