snappyHexMesh inclinced surface snapping problem
1 Attachment(s)
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:
Code:
Number of edges not aligned with or perpendicular to non-empty directions 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 |
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:
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 |
Quote:
Cheers, Antonio |
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 |
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.
|
Hi Tobi,
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. Regardless, if I land up with this problem in the future, I might try your idea anyway. Quote:
Regards, Thomas |
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:
Quote:
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). |
Quote:
https://www.dropbox.com/s/s3edq4rpr9...rWing.tar?dl=0 Cheers, Antonio |
3 Attachment(s)
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 |
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 |
3 Attachment(s)
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. |
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 What a relief ;) Regards Mojo |
Quote:
example : transformPoints -scale '(1e3 1e3 1e3)' |
yes exactly I did that.
Do you have an explanation for the failed mesh check? :) |
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 |
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. |
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 |
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).
|
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 |
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 |
All times are GMT -4. The time now is 22:36. |