Hey there,
It’s Robin from CFD Engine, back in your inbox with another weekly CFD note. This is one of the longer ones, but (hopefully) it’s easy going.
However, if you don’t have 5 mins…
TLDR: I ❤️
snappyHexMesh– but I get it if you don’t.
My CFD process rests heavily on snappyHexMesh. In fact it’s probably the bit that makes it all tick. I’m not sure I could have such an automated, distributed, cloud CFD workflow without it 🤔
But, I get why you might not dig it.
If you only need a couple of ultra-high-quality meshes a year for validating numerical methods, then snappyHexMesh probably isn’t for you.
If you absolutely must have 30+ layers on your boundaries then you & snappyHexMesh are not going to be friends.
If you need to prescribe a very specific first layer height, then you and snappyHexMesh will fall out.
If you need to churn out meshes in triple-quick time, then you might want to leave snappyHexMesh behind 🐌
If you need to specify precise edge-lengths on your patches, then snappyHexMesh does not have you covered.
If a crisp feature-edge is the highlight of your mesh, then you should probably look away now.
But…
If you need to mesh in parallel, snappyHexMesh can do that.
Scanned surface data? No CAD? No problemo.
Dirty / overlapping / intersecting / non-watertight input geometry – snappyHexMesh can probably figure it out & produce a mesh where others couldn’t.
But the biggest one, is that’s it’s a first-class OpenFOAM citizen.
No separate installation. No limits on mesh size, number of cores or how many instances you can run at once. It’s always up-to-date with the current OpenFOAM API – no conversion required. You can set boundary conditions at meshing time & it has the same quality measures as the solvers 👍
But…
It’s not all rosy in snappyHexMesh-land. Plenty of people struggle with it and plenty have decided that it’s not up to the job. If you’re switching from another code (& you’ve been using its mesher) then one of your first jobs is going to be to get to grips with snappyHexMesh & it’s not an enviable task. You’ve likely hit upon these (& more) hurdles…
This doesn’t look good
snappyHexMeshes often look “a little ragged” – hence the first rule of snappyHexMesh:
snappyHexMesh Rule #1 – Don’t Zoom In 🙈
Notice I said they don’t look good – they often solve really well, they just don’t look good on the surface.
A quick refresher: snappyHexMesh works by first creating a refined volume mesh, and then it reconstructs the surfaces from that volume mesh. You usually end up with a nice volume mesh, and with a surface mesh that doesn’t look quite as good as your input geometry.
Here’s the rub. In snappyHexMesh, your surfaces reflect the resolution of your volume mesh. If you want it to look better, you’re going to need to add more cells. You can try to fake it with feature edges. But, you’d be better off embracing that “SHM look” & let the results tell you if (& where) you need more mesh.
You can, of course, generate meshes with beautiful surfaces AND a superb volume mesh – it’s just that these meshes tend to be hand-crafted and they aren’t easily automated (unless you can throw A LOT of cells at them). Adaptive mesh refinement is another solution, but it’s not that widespread.
Until a better option comes along, I’ll take a decent volume mesh with ropey surfaces, over a ropey volume mesh with beautiful surfaces, any day.
Difficulties layering
“Difficulties” is putting it too lightly. If you want to build a mesh with 30+ layers (& TBH 10+ is probably pushing it 🤔 ) then you’re going to struggle in snappyHexMesh. A similar story awaits if you want a very specific first layer height or growth profile. Layers are hard to wrangle in snappyHexMesh. If they’re super-important to your model then be prepared to make some compromises &/or increase your grey hair count.
cfMesh layers suggest that snappyHexMesh could do better. But then again, if you want multiple regions, faceZones & curvature refinement, cfMesh falls short 🤷♂️
Expectation is everything
If you’re used to super-fast meshing, then snappyHexMesh might feel a little sluggish.
You might also have heard that "snappyHexMesh doesn’t scale well" and that chucking cores at it might not help as much as you’d hoped.
And man alive, does it eat up RAM. Peak memory usage (while meshing) is often way higher than the final mesh size would suggest. Result, the maximum size of your meshes is governed by snappyHexMesh memory usage, not by what you can fit in the solver.
But that’s the thing with expectations, they need to be managed.
snappyHexMesh is much faster than building meshes by hand & it doesn’t need you to babysit it while it’s meshing.
On scaling – I’ve parroted that scaling quote many times, but come to think about it, it might not be fair 🤔 I’m comparing it to solver scaling & it’s not a solver. Could it go faster? Running cfMesh suggests that it could, but perhaps not without a re-write.
Re memory usage – your mileage may vary. It often depends on the size (in MB) of your input geometry & how big the voids are in your model. snappyHexMesh meshes all the voids & then chucks away the bits you don’t want (or whatever it can’t reach). Big voids can mean big reductions in mesh size during meshing.
I still ❤️ SHM
All that said, I still think snappyHexMesh is great.
It’s not without it shortcomings. There are real showstoppers in there for some applications. But I think it’s worth the effort (and it can be a lot of effort) to get to know it. Then, push its limits & find out whether those limits are as important as you originally thought they were.
Are you on the snappyHexMesh train or did you have to get off before it turned your hair grey? Any tips you want to share with the class? What do you use instead? What should I be investigating? Do you need a hand with a snappy-related problem? Drop me a note, I might be able to help or, if not, I can commiserate with you 🍻
Until next week, may the mesh be with you,
