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

[snappyHexMesh] snappyHexMesh inclinced surface snapping problem

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

Like Tree16Likes
  • 1 Post By Swift
  • 4 Post By Tobi
  • 4 Post By Tobi
  • 2 Post By Tobi
  • 2 Post By Lorenzo92
  • 1 Post By Tobi
  • 2 Post By Tobi

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 18, 2016, 07:17
Default snappyHexMesh inclinced surface snapping problem
  #1
Member
 
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11
Swift is on a distinguished road
Dear Forum,

I have a plate with bent edges that will be located in a pipe. I have been having problems trying to get snappyHexMesh to snap to the bent surfaces. As you can see in the image attached, the sHM has snapped to the flat edges of the plate, but the mesh remains castellated on the bent edges.

I have orientated the blockMesh with the pipe axis. Consequently, the bent edges of the plate are inclined to the background mesh which I think may be causing problems.

The case file can be found at the following link.


I have tried the following in an attempt to get a better mesh:
  • I have increased the blockMesh resolution;
  • I have changed the resolve feature angle to 30, 45 and 90;
  • I have both increased and decreased the tolerance value. I have used values of 0.5, 1.0 and 2.0.
  • I have increased the allowable mesh properties. I changed these in an attempt to just get the mesh working, I realise that it will produce a bad mesh, I was only concerned that setting too stringent mesh quality controls restricts sHM too much
    • maxNonOrtho increased to 90 from 60;
    • maxBoundarySkewness increased to 40 from 10;
    • maxConcave increased to 90 from 45;
  • I think the plate geometry is adequately resolved to capture the detail.
  • I considered that sHM may not be meshing to the surface because it is very thin. To try eliminate this as a concern I increased the refinement level on the surface but to no avail. I also experienced a similar problem with other geometry. This geometry was a very thick orifice plate with a large chamfer, thereby creating a similar effect where the resulting surface is inclined to the blockMesh.
When I run checkMesh, the mesh fails with the following:
Code:
Number of edges not aligned with or perpendicular to non-empty directions
This is a 3D mesh.

Does anyone have a suggestion as to how to get the sHM to snap to the surface? I'm am not sure of all the parameters that can be adjusted in snappyHexMesh.

Thanks for your help,
Thomas
Attached Images
File Type: png Screenshot from 2016-07-18 10-27-54.png (96.1 KB, 609 views)
Swift is offline   Reply With Quote

Old   July 20, 2016, 03:49
Default
  #2
Member
 
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11
Swift is on a distinguished road
Greetings Forum,

I hope someone sees this thread and can still offer me some advice.

I have however found a way (at least on at first glance) to resolve the my meshing problem.

I tried a few further things to attempt to get a better solution but these did not work. I have only included these steps as a record for anyone who encounters this problem later. I tried the following:
  • replaced the sHM file with one of the master files from github. The reason for this was to work off a sHM template file without any changes that I had made;
  • thickened the geometry because of my concern with the mesh being too course to resolve the features. This could also be eliminated as a concern by increasing the refinement levels.

The step that eventually resulted in sHM snapping to the 'inclined surfaces' was to change the orientation of the blockMesh so that it was no longer aligned with the axis of the pipe. I didn't select any particular vector for the new blockMesh alignment, I just ensured that the mesh was not aligned to the axis.


I realise that generally sHM works better with blockMesh aligned to the surfaces of the geometry, but for whatever reason this seems to work. Presently, I have some skewFaces that I need to remove but that should be much easier.


Does anyone have a better explanation why not aligning the blockMesh with the geometry seems to result in a better snapped mesh? Is there a setting in sHM or surfaceFeatureExtractDict that might result in a better mesh rather than me fiddling with the blockMesh?


Kind regards,

Thomas
Swift is offline   Reply With Quote

Old   November 16, 2016, 03:55
Default
  #3
Member
 
Join Date: Jun 2011
Posts: 80
Rep Power: 15
maalan is on a distinguished road
Quote:
Greetings Forum,

I hope someone sees this thread and can still offer me some advice.

I have however found a way (at least on at first glance) to resolve the my meshing problem.

I tried a few further things to attempt to get a better solution but these did not work. I have only included these steps as a record for anyone who encounters this problem later. I tried the following:
replaced the sHM file with one of the master files from github. The reason for this was to work off a sHM template file without any changes that I had made;
thickened the geometry because of my concern with the mesh being too course to resolve the features. This could also be eliminated as a concern by increasing the refinement levels.

The step that eventually resulted in sHM snapping to the 'inclined surfaces' was to change the orientation of the blockMesh so that it was no longer aligned with the axis of the pipe. I didn't select any particular vector for the new blockMesh alignment, I just ensured that the mesh was not aligned to the axis.


I realise that generally sHM works better with blockMesh aligned to the surfaces of the geometry, but for whatever reason this seems to work. Presently, I have some skewFaces that I need to remove but that should be much easier.


Does anyone have a better explanation why not aligning the blockMesh with the geometry seems to result in a better snapped mesh? Is there a setting in sHM or surfaceFeatureExtractDict that might result in a better mesh rather than me fiddling with the blockMesh?
Hi Thomas! Did you solve that problem? I'm in the same point as you: I try to mesh an inclined flat plate with no success.

Cheers,
Antonio
maalan is offline   Reply With Quote

Old   November 16, 2016, 04:09
Default
  #4
Member
 
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11
Swift is on a distinguished road
Hi Antonio,

I did manage to resolve my problem. In my case I had an inclined plate in the first pipe diameter of a very long pipe. I meshed the inclined pipe region in a high resolution mesh and the long pipe length in another mesh. I then used mergeMesh to combine the two meshes. It was very time consuming, but it worked.

How does your case look? Do you have a very big domain with the inclined plate much smaller than your domain. I found that this was sometimes a problem.

Can you post your case? Maybe I can see if I can mesh it.

Thomas
lourencosm likes this.
Swift is offline   Reply With Quote

Old   November 16, 2016, 04:16
Default
  #5
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Tussenhausen
Posts: 2,708
Blog Entries: 6
Rep Power: 51
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
In my opinion just rescaling the whole mesh + STL files by a factor of 10000, meshing and downscale it again will also solve the problem. The picture seems to be like that the snapping procedure will undo all snapping iterations based on bad mesh qualities.
cutter, Bahram, lourencosm and 1 others like this.
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   November 16, 2016, 04:44
Default
  #6
Member
 
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11
Swift is on a distinguished road
Hi Tobi,
Quote:
In my opinion just rescaling the whole mesh + STL files by a factor of 10000, meshing and downscale it again will also solve the problem.
Are you suggesting that the stl files should be up-scaled but the same resolution initial blockMesh should be used with the same mesh refinements in SHM? This would result in the same mesh, just at the larger scale that would then be scaled down to the required dimensions. Or are you suggesting greater refinement should be used in both the blockMesh and SHM resulting in an overall higher quality mesh?

Do you have any idea why using larger geometry could solve the problem? To me it would seem that the scale should be irreverent in terms of meshing.

Regardless, if I land up with this problem in the future, I might try your idea anyway.

Quote:
The picture seems to be like that the snapping procedure will undo all snapping iterations based on bad mesh qualities.
In terms of the quality, it is strange because the same SHM dict and quality controls were used to mesh each of the sub-regions as was used to try and mesh the whole domain in one step. Only the blockMeshDict was changed. Meshing sub-regions worked but meshing the whole domain did not. This makes me think that SHM has problems dealing with small geometry and small refinements in very large domains. I have no idea as to the inner workings of sHM, so I don't know if this is plausible and I haven't tested that idea further.

Regards,
Thomas
Swift is offline   Reply With Quote

Old   November 16, 2016, 05:04
Default
  #7
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Tussenhausen
Posts: 2,708
Blog Entries: 6
Rep Power: 51
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
Dear Thomas,

if you ever get the problem again (of bad snapping, I mean that after snapping your mesh looks still somehow castellated), you should keep all options but just scale your background mesh (transformPoints -scale "(1000 1000 1000)") and your geometry (surfaceTransformPoints -scale "(1000 1000 1000)") and start snappy again. After you meshed the stuff, you should rescale to the original dimensions.

Quote:
Do you have any idea why using larger geometry could solve the problem? To me it would seem that the scale should be irreverent in terms of meshing.
You are wrong because during snapping and layering, snappy checks the mesh quality based on the input/or your own criteria. The problem that I can observe in your picture seems to be as follows:
  • Snappy tries to adopt the mesh points to the surface of your STL
  • It will fail based on the fact that some criterion are not fulfilled
  • Snappy will undo the snapping again
The problem occur, if you have very thin walls, or small dimensions. Of course you also could change all the mesh check criterion but I am too lazy for that. The interesting thing you mention is
Quote:
In terms of the quality, it is strange because the same SHM dict and quality controls were used to mesh each of the sub-regions as was used to try and mesh the whole domain in one step. Only the blockMeshDict was changed. Meshing sub-regions worked but meshing the whole domain did not. This makes me think that SHM has problems dealing with small geometry and small refinements in very large domains. I have no idea as to the inner workings of sHM, so I don't know if this is plausible and I haven't tested that idea further.

If it is like that, I am not sure why this happens. Never head this and the only thing that could be the problem might be your STL's (bad triangulation). Otherwise it should work without problems. I meshed already a lot of stuff with snappyHexMesh and after I used water proofed STL's and a good surface triangulation, I never had problems again.


I think your case is not big so if you will share it, I can check it and maybe I will learn something new

By the way, I also never checked the meshing algorithm (I mean the sources).
Bahram, koobide, Yanagi and 1 others like this.
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   November 16, 2016, 05:17
Default
  #8
Member
 
Join Date: Jun 2011
Posts: 80
Rep Power: 15
maalan is on a distinguished road
Quote:
I did manage to resolve my problem. In my case I had an inclined plate in the first pipe diameter of a very long pipe. I meshed the inclined pipe region in a high resolution mesh and the long pipe length in another mesh. I then used mergeMesh to combine the two meshes. It was very time consuming, but it worked.

How does your case look? Do you have a very big domain with the inclined plate much smaller than your domain. I found that this was sometimes a problem.

Can you post your case? Maybe I can see if I can mesh it.
Sure! You can download from this link:
https://www.dropbox.com/s/s3edq4rpr9...rWing.tar?dl=0

Cheers,
Antonio
maalan is offline   Reply With Quote

Old   November 19, 2016, 06:55
Default
  #9
Member
 
Lorenzo
Join Date: Oct 2015
Location: Graz
Posts: 49
Rep Power: 10
Lorenzo92 is on a distinguished road
Hi Foamers,

I think I bumped into the same problem: after snapping phase I end up having an undesired "castellated" effect on my mesh.
The mesh , which is quite refined, is for a DNS in a nasal cavity. Tobias, do you think it is related to the issue you pointed out ? ( I should have had to rescale the background mesh ,maybe with convertToMeters in blockMeshDict and my nasal stl?)
I included some pictures of the mesh after snapping phase

Thank you
Attached Images
File Type: jpg castellatedEffect2.jpg (28.6 KB, 322 views)
File Type: jpg castellatedEffect3.jpg (46.9 KB, 292 views)
File Type: png castellatedEffect.png (22.4 KB, 306 views)
Lorenzo92 is offline   Reply With Quote

Old   December 10, 2016, 19:46
Default
  #10
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Tussenhausen
Posts: 2,708
Blog Entries: 6
Rep Power: 51
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
Scale your background mesh and stl by 10000 and mesh it. Doing so, the result should be way better. However, I hope you have a good triangulated STL.

Sent from my HTC One mini using CFD Online Forum mobile app
lourencosm and Lorenzo92 like this.
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   December 11, 2016, 13:40
Default
  #11
Member
 
Lorenzo
Join Date: Oct 2015
Location: Graz
Posts: 49
Rep Power: 10
Lorenzo92 is on a distinguished road
Really thank you a lot! Indeed that was the problem. I worked it out rescaling everything according to your suggestion.

Hope this thread be useful for other snappy-users trying to mesh with very very deep refinement.
Attached Images
File Type: jpg noCastellated2.jpg (31.9 KB, 233 views)
File Type: jpg noCastellated1.jpg (25.5 KB, 204 views)
File Type: jpg noCastellated.jpg (32.9 KB, 231 views)
Tobi and lourencosm like this.
Lorenzo92 is offline   Reply With Quote

Old   December 29, 2016, 04:37
Default
  #12
New Member
 
Moritz
Join Date: Aug 2016
Posts: 14
Rep Power: 9
Mojo is on a distinguished road
Indeed, it helped me too. Thanks a lot!

Just wanted to share this observation with you, maybe you've seen the same:

I scaled my stl and mesh with factor 1000 and run sHM.
Then I run checkMesh and one check failed:
Code:
Error in face pyramids: 86 faces are incorrectly oriented
Although when I scaled it back and run checkMesh again, the incorrectly oriented faces did not exist anymore.

What a relief

Regards
Mojo
Mojo is offline   Reply With Quote

Old   December 29, 2016, 05:35
Default
  #13
Member
 
Lorenzo
Join Date: Oct 2015
Location: Graz
Posts: 49
Rep Power: 10
Lorenzo92 is on a distinguished road
Quote:
Originally Posted by Mojo View Post
Indeed, it helped me too. Thanks a lot!

Just wanted to share this observation with you, maybe you've seen the same:

I scaled my stl and mesh with factor 1000 and run sHM.
Then I run checkMesh and one check failed:
Code:
Error in face pyramids: 86 faces are incorrectly oriented
Although when I scaled it back and run checkMesh again, the incorrectly oriented faces did not exist anymore.

What a relief

Regards
Mojo
I assume you carried out homogeneous scaling in all directions, right?
example : transformPoints -scale '(1e3 1e3 1e3)'
Lorenzo92 is offline   Reply With Quote

Old   December 29, 2016, 07:17
Default
  #14
New Member
 
Moritz
Join Date: Aug 2016
Posts: 14
Rep Power: 9
Mojo is on a distinguished road
yes exactly I did that.
Do you have an explanation for the failed mesh check?
Mojo is offline   Reply With Quote

Old   December 29, 2016, 08:04
Default
  #15
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Tussenhausen
Posts: 2,708
Blog Entries: 6
Rep Power: 51
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
The error should be based on wrong oriented faces normals of the stl. You can check the face normals in paraview or blender...

Sent from my HTC One mini using CFD Online Forum mobile app
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   December 30, 2016, 07:25
Default
  #16
New Member
 
Moritz
Join Date: Aug 2016
Posts: 14
Rep Power: 9
Mojo is on a distinguished road
yes, makes sense. Thanks!
What I don't get is, why scaling eliminates the wrong oriented faces normals. Because when I scale back [transformPoints -scale '(0.001 0.001 0.001)'] the wrong oriented faces are gone.
Mojo is offline   Reply With Quote

Old   January 2, 2017, 11:23
Default
  #17
Senior Member
 
Join Date: Mar 2010
Location: Germany
Posts: 154
Rep Power: 16
cutter is on a distinguished road
Hi,

I observed the same problem with one of my own geometries. The workaround using transformPoints and surfaceTransformPoints proposed by Tobi in one of the former posts worked for me as well.

I want to obtain some more insight and find a solution that prevents this (still very useful) workaround. I would therefore like do a parameter study on the entries in system/snappyHexMesh and system/meshQualityDict. Could you please provide some hints regarding the relevant parameters?

Many Thanks!
Cutter
cutter is offline   Reply With Quote

Old   January 9, 2017, 03:08
Default
  #18
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Tussenhausen
Posts: 2,708
Blog Entries: 6
Rep Power: 51
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
The parameters in the sHMDict should be obvious (maybe not all in the layer) but there is a documentation from ENGYS (https://openfoamwiki.net/images/f/f0...SlidesOFW7.pdf). Here you will find all necessary information (not all but most of them).
lourencosm likes this.
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   January 18, 2017, 03:58
Default
  #19
Member
 
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11
Swift is on a distinguished road
Greetings everyone,

I have been silent on this topic for a while.

I am glad that there has been some success for people with similar problems by scaling the geometry up by several orders of magnitude, meshing and then rescaling back to the desired size.

Unfortunately, for me this approach did not seem to work, but I believe that I have found a solution (at least to my problem) that I would like to share for others who may find themselves in this situation later.

My problem was that I had a custom orifice plate within a pipe that would remain castellated after meshing. I found that the orifice plate stl file was fine. I tested this by removing all other geometry when meshing and only meshing the orifice plate within the blockMesh background mesh. For this test the orifice was meshed properly, even at low blockMesh resolutions, and stl file qualities. Only when I added the pipe stl file and attempted to mesh with the combination of the orifice plate and pipe did I have the castellated problem. The pipe would mesh properly on its own.

I resolved this by editing the blockMesh file. The initial blockMesh fit tightly around my geometry to increase mesh time. I found that by extending the blockMesh in all directions and refining the blockMesh so that the resolution was the same as the initial mesh.

I hope this makes sense.

I guess the problem is resolved.

Thanks to everyone who helped.

Thomas
Swift is offline   Reply With Quote

Old   January 18, 2017, 04:42
Default
  #20
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Tussenhausen
Posts: 2,708
Blog Entries: 6
Rep Power: 51
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
Yes it makes sense.

However, everybody who has problems with snappyHexMesh / meshing in general can check out my screencasts: http://www.holzmann-cfd.de/index.php/en/teaching
lourencosm and allanZHONG like this.
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Reply

Tags
inclined surface, snap controls, snappyhexmesh

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 Boundary Layer at Corner panpanzhong OpenFOAM Meshing & Mesh Conversion 5 July 3, 2018 05:53
[snappyHexMesh] SnappyHexMesh Patch Problem Perschr OpenFOAM Meshing & Mesh Conversion 0 October 8, 2016 12:09
[snappyHexMesh] SnappyHexMesh : snapping not matching surface Awak OpenFOAM Meshing & Mesh Conversion 4 May 31, 2016 08:23
[ICEM] surface mesh merging problem everest ANSYS Meshing & Geometry 44 April 14, 2016 06:41
[Gmsh] Problem with Gmsh nishant_hull OpenFOAM Meshing & Mesh Conversion 23 August 5, 2015 02:09


All times are GMT -4. The time now is 09:00.