[Swift]

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:

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

[Swift]

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

[maalan]

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

[Swift]

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

[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.

[Swift]

Hi 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.

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.

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

[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.

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

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).

[maalan]

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

[Lorenzo92]

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

[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

[Lorenzo92]

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.

[Mojo]

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:

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

[Lorenzo92]

Originally Posted by Mojo

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:

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)'

[Mojo]

yes exactly I did that.
Do you have an explanation for the failed mesh check?

[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

[Mojo]

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.

[cutter]

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

[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).

[Swift]

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

[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