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

[snappyHexMesh] Layers Damaging Initially Well Snapped Edges

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

Like Tree2Likes
  • 1 Post By HPE
  • 1 Post By HPE

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   May 8, 2020, 12:02
Default Layers Damaging Initially Well Snapped Edges
  #1
New Member
 
Conor Crickmore
Join Date: Jan 2020
Location: Leicestershire, United Kingdom
Posts: 24
Rep Power: 2
cjc96 is on a distinguished road
Hello everyone,
In what seems to be a rite of passage for OpenFOAM and snappyHexMesh I am currently having an argument with prism layers.

I see a lot of problems relating to layers not fully covering sharp edges, but I've yet to find an example of my own problem, where the layers are seemingly pulling the initially well-snapped mesh away from the surface. I'm not really sure how best to explain it, so I've included a few images.

Here you can see the mesh without layer addition, with the cells well snapped to the surface of the .stl representing my domain. I know such a domain could be made using blockMesh, but I was experiencing some other issues using that method so am attempting this as an alternative.

Here you can see the result following the addition of prism layers. You can see that where there was original a sharp corner, a tapered edge has been produces, and downstream, a large number of malformed cells are visible on the lower edges.

Due to the pandemic I am working from home which is significantly increasing the time required to produce each mesh. I have been playing around with the settings in both 'snapControls' and 'addLayerControls', most notably the smoothing operations and primary iteration settings (including 'nFeatureSnapIter') but to no avail.

As a slight aside, one of the problems I was facing when using blockMesh to explicitly define my domain was that my prism layers were 'bulging' across the faces of the domain and 'compressing' (but not collapsing) towards the edges. I think it is to do with the fact that the domain has a slight divergence in width across its length, but had no luck counteracting that either.

I hope everyone is staying safe in these crazy times, and would me immensely grateful if any of the snappy wizards out there could shed some light on these issues.
__________________
Conor Crickmore
PhD Researcher in Automotive Aerodynamics
Aeronautical and Automotive Engineering
Loughborough University
LE11 3TU
cjc96 is offline   Reply With Quote

Old   May 8, 2020, 13:29
Default
  #2
HPE
Senior Member
 
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 583
Rep Power: 5
HPE is on a distinguished road
Hi,

- I assume the castellated and snap controls in the first and second meshes are the same? Therefore, you only turn on the addLayer controls for the second mesh, and it somehow moves the patch faces as shown in the second figure. Would you mind to confirm?
- Is there any chance for you to attach the relevant dictionaries to be able to reproduce the problem?
- I am not really an expert on meshing, but would some of the fine tuning settings help for your addLayer control?: https://www.openfoam.com/documentati...sh-layers.html
- I am surprised that the addLayer distorts the already existing patches. Interesting.
HPE is offline   Reply With Quote

Old   May 8, 2020, 13:51
Default
  #3
New Member
 
Conor Crickmore
Join Date: Jan 2020
Location: Leicestershire, United Kingdom
Posts: 24
Rep Power: 2
cjc96 is on a distinguished road
Quote:
Originally Posted by HPE View Post
Hi,

- I assume the castellated and snap controls in the first and second meshes are the same? Therefore, you only turn on the addLayer controls for the second mesh, and it somehow moves the patch faces as shown in the second figure. Would you mind to confirm?
- Is there any chance for you to attach the relevant dictionaries to be able to reproduce the problem?
- I am not really an expert on meshing, but would some of the fine tuning settings help for your addLayer control?: https://www.openfoam.com/documentati...sh-layers.html
- I am surprised that the addLayer distorts the already existing patches. Interesting.
Hey HPE,
Yes, exactly that, the only changed made between the two images was turning on layer addition!

I'll be honest, I keep forgetting how good the documentation on openfoam.com can be at times and hadn't stumbled across those keyword sections, that will definitely be tomorrow's job!

I've attached the relevant working directory, I tried to remove all the useless fluff relevant to my actual work, and may have forgotten to properly remove a reference or something so let me know if it doesn't run at all!
Attached Files
File Type: zip Test_Block_STL.zip (13.1 KB, 1 views)
__________________
Conor Crickmore
PhD Researcher in Automotive Aerodynamics
Aeronautical and Automotive Engineering
Loughborough University
LE11 3TU
cjc96 is offline   Reply With Quote

Old   May 8, 2020, 13:59
Default
  #4
HPE
Senior Member
 
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 583
Rep Power: 5
HPE is on a distinguished road
Thanks,

So the order of execution for the reproduction: "blockMesh + snappyHexMesh" or directly "snappyHexMesh"?
HPE is offline   Reply With Quote

Old   May 8, 2020, 14:03
Default
  #5
New Member
 
Conor Crickmore
Join Date: Jan 2020
Location: Leicestershire, United Kingdom
Posts: 24
Rep Power: 2
cjc96 is on a distinguished road
Quote:
Originally Posted by HPE View Post
Thanks,

So the order of execution for the reproduction: "blockMesh + snappyHexMesh" or directly "snappyHexMesh"?
You would do blockMesh > surfaceFeatures > snappyHexMesh

The version I sent over will probably produce a mesh in the region of about 5m cells with the layers enabled, so you'll need at least 16GB of RAM and I'd recommend running snappy in parallel
__________________
Conor Crickmore
PhD Researcher in Automotive Aerodynamics
Aeronautical and Automotive Engineering
Loughborough University
LE11 3TU
cjc96 is offline   Reply With Quote

Old   May 8, 2020, 14:18
Default
  #6
HPE
Senior Member
 
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 583
Rep Power: 5
HPE is on a distinguished road
Oh, thanks for warning. Then I will need a proper machine for which I will have an access to on next Tuesday. I'm sorry for this (hope you resolve the issue till then).
cjc96 likes this.
HPE is offline   Reply With Quote

Old   May 8, 2020, 14:21
Default
  #7
New Member
 
Conor Crickmore
Join Date: Jan 2020
Location: Leicestershire, United Kingdom
Posts: 24
Rep Power: 2
cjc96 is on a distinguished road
Quote:
Originally Posted by HPE View Post
Oh, thanks for warning. Then I will need a proper machine for which I will have an access to on next Tuesday. I'm sorry for this (hope you resolve the issue till then).
No worries bud, I appreciate it is a fairly hefty case, it will ultimately be for external aerodynamics calculations for which I have access to HPC hardware
__________________
Conor Crickmore
PhD Researcher in Automotive Aerodynamics
Aeronautical and Automotive Engineering
Loughborough University
LE11 3TU
cjc96 is offline   Reply With Quote

Old   May 8, 2020, 15:03
Default
  #8
HPE
Senior Member
 
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 583
Rep Power: 5
HPE is on a distinguished road
- I have managed to reproduce the issue, but difficult to proceed to analyse it without a proper machine, so Tuesday (again
- So one potential problem is that the blockMesh boundingBox is similar to that of "Tunnel.stl". Typically, blockMesh domain would be larger than the surface meshes you would like to snap in each direction. Assuming you would like to simulate the flow inside "Tunnel.stl" only, could you please create a much larger blockMesh, and then snap onto the STL files you have created?
- One observation: the STL files (i.e. surface meshes) are pretty coarse (e.g. Tunnel_Inlet_Section.stl has 8 triangles in total, it seems). To my experience, snappyHexMesh does not like to work on coarse surface meshes in general. Is it possible to create a finer surface mesh for you?
- Could you please visually check the feature edges produced by surfaceFeatures (*.eMesh files)?
- More potential observations on Tuesday, or a bit even later, depending on my workload. Thanks for your understanding.
cjc96 likes this.
HPE is offline   Reply With Quote

Old   May 8, 2020, 15:13
Default
  #9
New Member
 
Conor Crickmore
Join Date: Jan 2020
Location: Leicestershire, United Kingdom
Posts: 24
Rep Power: 2
cjc96 is on a distinguished road
Quote:
Originally Posted by HPE View Post
- I have managed to reproduce the issue, but difficult to proceed to analyse it without a proper machine, so Tuesday (again
- So one potential problem is that the blockMesh boundingBox is similar to that of "Tunnel.stl". Typically, blockMesh domain would be larger than the surface meshes you would like to snap in each direction. Assuming you would like to simulate the flow inside "Tunnel.stl" only, could you please create a much larger blockMesh, and then snap onto the STL files you have created?
- One observation: the STL files (i.e. surface meshes) are pretty coarse (e.g. Tunnel_Inlet_Section.stl has 8 triangles in total, it seems). To my experience, snappyHexMesh does not like to work on coarse surface meshes in general. Is it possible to create a finer surface mesh for you?
- Could you please visually check the feature edges produced by surfaceFeatures (*.eMesh files)?
- More potential observations on Tuesday, or a bit even later, depending on my workload. Thanks for your understanding.
Awesome!
Thanks so much for your time HPE. It's just gone 8pm here in the UK so I think I'm going to call it a night, go for a run and clear my head but I will be sure to have a tinker in the morning.

You are certainly right about the files being pretty coarse, I just assumed that since they were such simple shapes, it wouldn't be a problem, but I'll export them at a higher quality and see.

The blockMesh bounding box is more or less 1m larger than the 'tunnel' in each direction, so is ~ 0.5m away from each patch. Given the standard (level 0) cells are 0.04m do you really think it is too small? It obviously isn't a big deal to extend it, but I am surprised this could be part of the issue.
__________________
Conor Crickmore
PhD Researcher in Automotive Aerodynamics
Aeronautical and Automotive Engineering
Loughborough University
LE11 3TU
cjc96 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] snappyHexMesh sticking point natty_king OpenFOAM Meshing & Mesh Conversion 10 August 5, 2019 19:18
SimpleFoam & Theater jipai OpenFOAM Running, Solving & CFD 3 June 18, 2019 10:11
[snappyHexMesh] Help with Snappy: no layers growing GianF OpenFOAM Meshing & Mesh Conversion 1 December 12, 2017 04:44
[snappyHexMesh] sHM layer process keeps getting killed MBttR OpenFOAM Meshing & Mesh Conversion 4 August 15, 2016 03:21
[snappyHexMesh] No layers in a small gap bobburnquist OpenFOAM Meshing & Mesh Conversion 6 August 26, 2015 09:38


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