[cjc96]

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.

[HPE]

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.

[cjc96]

Originally Posted by HPE

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!

[HPE]

Thanks,

So the order of execution for the reproduction: "blockMesh + snappyHexMesh" or directly "snappyHexMesh"?

[cjc96]

Originally Posted by HPE

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

[HPE]

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]

Originally Posted by HPE

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

[HPE]

- 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]

Originally Posted by HPE

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