[cjm]

Hej community,

Is it possible to control the y+ values of my grid in some way with sHM? I have values from 16 to 4000 and I would rather have them between 30 and 300 using wall functions...

The question came up in this discussion which I had yesterday.

http://www.cfd-online.com/Forums/ope...e-problem.html

Thanks, Carl

[mmcs21]

hi carl

did you ever get a solution to this? i know it was long time ago....

I'm studying turbulence over an oilrig and have meshed my geometry using snappyHexMesh. would really like to be able to contrain y+ values to be in appropriate range.

thanks

[fedvasu]

I am using snappyHex for meshing rotating fan, I am having hard time getting y+ down to 1, using y+, giving a very small finallayer thickness wouldn't add the layer at all and with larger finalLayer thickness and small expansion ratio at the very best I reached,average y+ of 55 over my blade surface.

So, should I give up on snappyHex or use some scaling tricks or anything else??

Anyone? My detailed question is http://www.cfd-online.com/Forums/ope...ers-y-1-a.html

[pbachant]

Originally Posted by fedvasu

I am using snappyHex for meshing rotating fan, I am having hard time getting y+ down to 1, using y+, giving a very small finallayer thickness wouldn't add the layer at all and with larger finalLayer thickness and small expansion ratio at the very best I reached,average y+ of 55 over my blade surface.

So, should I give up on snappyHex or use some scaling tricks or anything else??

Anyone? My detailed question is http://www.cfd-online.com/Forums/ope...ers-y-1-a.html

You can try refining the background mesh, and turning up the refinement at the fan surface. I've never been able to add more than 20 layers, and that's rare. 12--16 is more reasonable. I keep finalLayerThickness around 0.5, with an expansion ratio 1.2--1.3. Refinement at the surface I usually use level 5. Level 6 slows things down a lot.

[fedvasu]

Originally Posted by pbachant

You can try refining the background mesh, and turning up the refinement at the fan surface. I've never been able to add more than 20 layers, and that's rare. 12--16 is more reasonable. I keep finalLayerThickness around 0.5, with an expansion ratio 1.2--1.3. Refinement at the surface I usually use level 5. Level 6 slows things down a lot.

good idea, I am actually just trying to increase refinement level without making background mesh finer, at level 7 + 6 layers with final layer thickness of 0.15 I am at about average y+ = 5.

I will definitely try it out, thanks.

[seaspray]

I have had a 3-week long battle with SHM to try and obtain good reliable layers for resolving the boundary layer around yacht hulls and... lost it in some way: I was forced to devise a workaround. I tried just about every possible combination of background mesh, refinement and mesh growing parameters with much systematic testing after reading and studying every piece of material I could find on the subject.

Two key issues could never be alleviated reliably. Layers disappearing towards the corners and layers suddenly collapsing and growing back at the symmetry plane (I compute a half-domain) typically when the surface is not aligned with the background hex mesh. The latter starts happening when augmenting the number of layers. The OF examples including the DTC hull do suffer from this issue by the way with just 3 layers only and the DTC hull is very favourable with long straight lines aligned with the hex mesh. I would also mention that substituting a "fully curved" STL geometry of similar size in one of these cases resulted in a total disaster. The input was Hull #62 of the Delft series.

The best I achieved was growing 7 reasonable layers still with some corner and layer density problems. Then I made a minute change to the background mesh and the whole edifice collapsed. My layers disappeared into the surface only to re-appear a little further.

Early in the process, I separated the layer growing phase using two dictionaries for SHM, so I could archive and quickly restore the snapped mesh while trying to grow layers.
The snapping algorithm has reached a decent level of maturity in OF 2.3.0 provided some basic principles are respected with the background mesh, but the layers algorithm is far from robust in my opinion.
What is offered here is aimed at trying to improve it, so bear with me.

What I learned can be presented this way, starting with refining and snapping:

- SHM works better when the refinement level is uniform around the object and surface features are previously extracted and made available, especially in the context of growing layers afterwards.
- I snap hexes that have an aspect ratio of 1 or very close to it.
- If needed, I script a topoSet and refineMesh approach to select and refine the regions I am interested in, rather than relying on the built-in refinement of SHM. This is especially valuable if refinement is also needed in regions that are not related to the STL geometry. Using a Z-axis refinement followed by a XY refinement allows creating cells of different aspect ratios in some areas and still end up with perfect uniform cubic cells surrounding the geometry.

The layers battle is the one I lost as far as SHM is concerned. I need to be able to produce very reliable, good-quality boundary layer meshes down to a very small Y+ value for regions where the pressure gradient is not positive, i.e. stern sections here and I need to be able to substitute geometries of comparable size and remesh without having to go through lengthy trial-and-error with the multitude of input parameters of the layer growing process and repeated visual inspection.

I found that I can grow one good layer around the geometry with SHM in a reliable and dependable way. Growing more sometimes succeeds and sometimes fails with the exact same background mesh and parameters for no logical reason. I can grow this one layer to whatever thickness I want within reason, from a fraction to twice or more the size of my uniform background mesh if I want.

Based on the above, I designed a wall layer refinement scheme that decomposes one thick SHM-grown layer into a set of gradually thinning layers when moving towards the surface, following a geometric progression. I reached a much better outcome overall with this strategy, rather than fighting with SHM on a case-by-case basis. I currently generate 10 layers every time this way, and I might increase this number soon.

Advantages were immediate:

- With a very high quality background mesh, snapping is reasonably fast and so is growing one single layer.
- The layer goes around corners reliably, its thickness doesn't vary much and it doesn't collapse locally.
- Refining the layer is fast and efficient; hugely faster than trying to grow multiple layers in SHM.
- The outcome is very consistent and predictable in visual terms.
- The approach has so far mostly produced meshes without serious quality issues - keep reading.

The drawback is that unlike in SHM, wall layer refinement takes place without mesh quality control. I have once had an issue with the thinnest, innermost layer resulting from the refinement. It caused the solver to diverge and I had to drop it. I believe that another pass merging micro-cells after wall layer refinement would be a significant improvement.

Based on all the above, I wonder whether the layers algorithm in SHM should not be reconsidered altogether to implement a better version of the process highlighted above: grow one single thick layer and then geometrically refine it with mesh quality checking.
I believe it would be immensely faster and more reliable than the present process of growing consecutive layers outwards. It rapidly leads to cumulative problems and failure.

As I am sure that many here have gathered considerable experience with SHM, it would be interesting to see whether support exists for such an approach. So here it is!

Best regards,

Eric

[fedvasu]

seaspray,

I am impressed at the amount of systematic observation and correlations found.
I too gave up after trying varying levels of background refinmenet, number of layers and other quality parameters.

have written the code to decompose that one SHM generated layer?
you mentioned that mesh quality parameters can't be used with it, did you try it on say more than 3 shapes?

I too have the problem of not able to get y+ < 2, I have curved ceiling fan blade, over which I need to generate those layers.

All suggestions welcome.

[seaspray]

fedvasu,

I refine the single grown layer using a series of scripted calls to refineWallLayer with strategically defined refinement ratios:

# Strategic wall refinement of a single grown layer
# 10-layer scheme, 1.25 growth ratio
refineWallLayer -overwrite hull 0.7759419501
refineWallLayer -overwrite hull 0.768995039
refineWallLayer -overwrite hull 0.759681195
refineWallLayer -overwrite hull 0.7469266776
refineWallLayer -overwrite hull 0.7289444011
refineWallLayer -overwrite hull 0.7025226083
refineWallLayer -overwrite hull 0.6612466125
refineWallLayer -overwrite hull 0.5901639344
refineWallLayer -overwrite hull 0.4444444444

For now I just work out the refinement factors in a spreadsheet, but an algebraic expression should be able to be derived to give these figures for any number of layers and progression ratio.

Mesh quality only applies to the work performed by SHM, so it does apply to the single grown layer. One you start subdividing it with refineWallLayer, it doesn't apply because the utility doesn't look at the SHM dictionary. I have just found by experience that if the starting layer is very good, the refined layers have a tendency to be good as well within reason, which is the exact opposite of what happens with SHM trying to grow them outwards.

I have thought about hacking SHM to change the way it operates, but this would take a lot of time because I am not familiar with the way the mesh is stored in memory and all the internal data structures in OF. Also I am trying to do a CFD job here, rather than a software one... the most efficient pathway would be working with the authors of SHM who could change it far more efficiently than anyone else if the concept appeared to find support. It is not such a huge task when you think about it, because the layer growth code is there, the layer refinement code also exists and the only requirement is developing a new mesh quality improvement scheme for refined layers.

I have used this approach with several geometries and so far it has been "this way or give up", which is not an option.

Best regards,

Eric

[pbachant]

Eric,

That's quite clever. I'm going to need to try that. What do you generally use for a finalLayerThickness in the sHMDict?

[seaspray]

Pete,

I generate a hex mesh with cubic cells of 0.015m around the geometry and then I grow one layer in SHM with a size relative to the background mesh and set to 2.
My STL geometry is about 2m long to give you an idea of relative proportions. It is very important to get a good clean snap in the first place with correct feature angles etc to get clean corners.

This means I then have more or less 30mm available for layers refinement.

You might want to experiment with using an absolute size instead (I saw it working at times), but SHM seemed more reliable overall with a relative size. Not a definite statement however!

Best regards,

Eric

[fedvasu]

seaspray,

thanks for your reply, I will definitely try out post my observations.

are doing this hull project as part of your thesis or you are in Industry?

Regards

[pbachant]

I started playing around with this algorithm a bit, with good results. I wrote a Python script to automate things:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
This script refines wall layers in OpenFOAM meshes. A single thick layer should be generated
with `snappyHexMesh`.
"""
import subprocess
import numpy as np

# Input parameters
nlayers = 18
expansion_ratio = 1.25
patches = ["shaft", "blades"]

# Compute all cell heights starting at the wall
c = [1]
for n in range(nlayers-1):
    c.append(expansion_ratio*c[n])
c = np.asarray(c)

# Normalize cell heights so sum = 1
c = c/c.sum()

# Compute splitting ratios between all cells
s = [np.sum(c[0:-1])]
for n in range(1, nlayers-1):
    s.append(np.sum(c[0:-n-1])/np.sum(c[0:-n]))

# Run OpenFOAM utility to split wall layers
for patch in patches:
    for ratio in s:
        cm = "refineWallLayer -overwrite " + patch + " " + str(ratio)
        subprocess.call(cm, shell=True)

[seaspray]

Nice move. This is how my spreadsheet calculated it indeed. An interesting property of the series is that for a given expansion ratio, the refinement coefficient for layer i is always the same, regardless of the number of layers and final thickness of all the layers.

Since the sum of a geometric series can be calculated using a simple algebraic relation, we can come up with a formula for the refinement ratio R for layer i with a progression ratio lambda. It is surprisingly simple and tidy:

                   lambda^(i-1) - lambda^i
R(i, lambda) = 1 - -----------------------
                        1 - lambda^i

Refinements for a N-layer scheme therefore require N-1 calls to refineWallLayer with R(i, lambda) using values of i starting at N and finishing at 2: two of course, because layer 1 is naturally left behind by the subdivision process.

Scripting it in a flexible way is definitely the way to go.

Eric

[seaspray]

I scripted the above equation as part of my numerical towing tank setup, I am attaching the result here for those who might want to experiment with the method.

Bash scripts tend to look like some bad attempt at cryptography... and this one is hardly an exception. Most of it has to do with arguments checking and the business end is one single line in a small loop.

Usage:

refineLayerMesh <patchName> <numLayers> <expansionRatio> [stopLayer]

The optional stopLayer parameter has a default value of 1 and allows ending the layer splitting process before it completes:

Calling refineLayerMesh hull 9 1.25 1 is equivalent to refineLayerMesh hull 9 1.25 and will refine one grown cell layer from SHM into a geometric progression of 9 layers towards the surface.

Calling instead refineLayerMesh hull 9 1.25 2 will stop the refinement process one layer short, etc.
This can be useful when some of the thinner inner layers develop mesh quality issues and crash the solver.


Someone was asking above whether it is research or professional for some reason: one foot in each camp at the moment. It depends on what goes into the tank and why and it is work in progress. I have had very positive results with viscous resistance and resolving the boundary layers using this meshing scheme.

And remember, the objective is trying to come up with a pathway for improving the implementation of the horrible snappyHexMesh layers algorithm for everyone, not offering some workaround! This should be done with integrated mesh quality control, so if it looks promising for you, say it and say it in the right places.

Best regards,

Eric

[robo]

Seaspray,
I haven't tried your script, however I've been using the same method as you, for the same reasons. Unfortunately, I have not had as much success as you seem to, and I am frequently encountering an error while trying to use refineWallLayer that says that the "anchorpoints and non-anchorpoints are on the same side". This error causes there to be open cells in the domain, which ruins the process. I was wondering if you encountered this at any point while you were working on your own method, and if you have any recommendations to help avoid it?

[seaspray]

Robo,

I have never run into this error so far within this context. Is it a result of refining to an extremely thin inner layer (it almost sounds like it), i.e. near the end of the process, or does it happen at the start?

Because I have split my SHM process into a snap and then layer grow phase, when I set up a new environment (new background mesh, different size geometry) I visually inspect the snapped mesh and the grown layer before refining.
Once this has been done, I can normally substitute geometries without looking at the mesh, but keep in mind that I always mesh the "same kind of stuff" more or less. If I suddenly introduced something much more exotic and complicated, it might not go that well without at least reviewing the parameters for SHM.

I do however remember refineWallLayer failing - possibly with this error - when I tried refining meshes that had not been intended for that, i.e. bad multi-layer meshes from SHM, meshes that weren't wall parallel etc.

I would suggest going back and checking the previous stages and then also making sure you are not trying to refine down to incredibly thin layers, which happens very quickly with geometric progressions.
If you look above, in Pete's Python script, he coded 18 layers with a growth ratio of 1.25: that is a ratio of 55 between the thickest and thinnest layer... this could be a tough test.

I try to work out roughly what y+ = 1 should look like in the regions of interest and I try to approach this value with the refinement and no more. The thickness of my original SHM-grown layer is calculated to more or less contain the entire boundary layer (99% freestream velocity) where I want it solved rather than bridged by wall functions. At the moment I am using 8-9 mesh layers with a growth ratio of 1.25 to resolve the boundary layer and it seems to be behaving for the size of problems I am dealing with, but it may not be the final word.

[robo]

It happens fairly early in the process, at the third or fourth wall normal refine. My geometry is an ice-breaker, and is not as wall-parallel as yours appears to be. I have inspected the mesh before the refine, and the snap is good, however the single layer addition gets quite thin in certain places, which is where I believe the failure is occurring. I have had little luck getting the thin region to thicken so far. I am trying to refine down to y+=100 as wall functions are acceptable for the analysis I need to run. I am aiming for a similiar growth to your own; 7 layers at 1.2 growth rate.

I am very new to snappyHexMesh, and am not very familiar with it's quality controls. I had initially planned to do the mesh generation in Pointwise, as it has much better controls for wall normal resolution, however I found that the Pointwise to openfoam export was not reliable, so I'm trying to use SHM.

[seaspray]

Ok. My geometry is anything but aligned with the background hex mesh, all surfaces are significantly and continuously curved. What makes the mesh wall-parallel is the layer addition in SHM.
I would pay great attention at the size of the hex cells supplied to SHM and also in relation with the thickness of the layer you then need to grow. You can grow a layer of a size relative to the background mesh or of an absolute size in SHM. Unless this layer is very consistent, refinement issues can be expected and the final mesh is unlikely to be good computationally anyway.

I have never altered the quality control parameters in SHM by the way, only mesh generation parameters.

In the case of a ship, stern shapes are often more tortured than what is found on yacht-type hulls. As long as the pressure gradient is positive, the velocity gradient from the surface has a chance to follow the log law assumption and wall functions may remain valid, but towards the stern it is most unlikely that they would apply at all and short of solving the boundary layer the result won't have much value. This means meshing the zone 0 < y+ < 30 or so with sufficient resolution.
Wall functions can help on the forward part of the hull where the boundary layer is thin and would require an incredibly tight mesh to solve it.

I would work out where the goal posts are in terms of mesh sizes/density and then focus on achieving this through mesh construction, otherwise you could spend a lot of effort building a mesh that is not adequate to analyze the problem anyway. Obtaining good computational results is no straightforward task at all, especially for viscous forces which are dominant for large vessels.

Anyway - this is somewhat besides the point here, but all the best.

[seaspray]

A few more words in the way of a temporary conclusion... while the approach I described earlier delivered some encouraging results, in the end meshing still wasn't robust enough overall. Not only the layer generation scheme was a workaround only, but I also had recurring snapping problems, typically in the region of the bow and forefoot that could not be explained by or blamed on the input geometry. These problems caused discontinuities and invalid meshes with wrongly oriented faces typically and crashed the solver afterwards.

It came down to the reliability of the algorithm and stepping back to re-tweak the senseless number of parameters that control the execution of SHM in order to obtain a more or less acceptable output while meshing a simple, basic, fully convex curved body made no sense. Such a simple geometry should mesh without leading to crazy behaviours and it became time to move on.

I have reservations when it comes to the use of STL geometry as an input. Compared to a NURBS-based input, STL essentially loses all of the topological information and features and those have to be hopefully extracted again correctly for hex-snapping to have a chance to work properly. An IGES file on the other hand contains surfaces and trim curves allowing intersections to be calculated without having to deal with a multitude of tiny facets sharing edges. Furthermore, there is no harm snapping hexes to a trim curve, even if it doesn't represent a feature, but the same cannot be said of failing to snap to an edge because the former trim curve was lost.

Considering the number of years SHM has now been around for and the amount of time it must have wasted by consistently failing to fulfill its promises, I have come to wonder whether this road is not simply coming to a dead-end.

I first moved my meshing operations to the Salome platform, with the attractive prospect of Python scripting combined with a GUI and a direct mesh data export to OpenFOAM, thanks to an open-source script.
I am inclined to believe that Salome will be the pathway for meshing OpenFOAM cases with open-source code, even though it still has some distance to go when it comes to catering for complex problems. Hexa meshing capability is limited and I ran into too many bugs (version 7.3.0) to pursue when I tried to subdivide the fluid domain into regions to generate a hybrid mesh, but the geometry module is very good and the meshing module much more promising than OpenFOAM meshing tools, including and especially when it comes to generating 3D viscous layers. The development and release cycle is also shorter and appears better supported with French industrial interests behind it.

With none of the overset grid work done in OpenFOAM being released, at the moment this seems to leave commercial CFD mesh packages only for complex situations and certainly for marine hydrodynamics with a free-surface if the objective is more than just creating a pretty picture.

[pbachant]

seaspray,

I tried SALOME a little in the past, but could not figure out how to make boundary layer meshes with it. Do you have any good resources for this?