Hey there,
It’s Robin from CFD Engine & I’ve got a freebie for you today. You can start using it right away, there’s nothing to download or install & yet I see plenty of people ignoring it.
It can reduce your error rate, improve your meshing and make it easier to automate your process.
It can increase the flexibility of your models, reduce the size of your dictionaries and increase their readability.
It can also make it easier to onboard new team members.
What is it? You’ve probably already guessed – it’s the humble naming convention.
If you have one, then you’re probably nodding along.
If you don’t, then developing a naming convention for your models could easily be one of your best investments in CFD.
Let me see if I can convince you…
What’s in a name?
I’m a sucker for a good naming convention. I started CFDing in a place where naming conventions were bestowed with near-mystical powers. Name your surfaces wrong & the whole process started to fall apart.
Unsurprisingly, that made me super-sensitive to what things were called and the opportunities that arise when you have a neat naming convention.
It’s also one of the first things I notice when I get a sneak peak into other people’s CFD models. There’s always some naming convention, an inlet & outlet at the very least, but they could be getting so much more out of it.
Wildcards
To be more accurate, it’s the combination of a decent naming convention and the ability to use wildcards (or regular expressions) in your dictionaries, that make the magic happen.
You can use regular expressions almost anywhere that you can specify a name in OpenFOAM – from boundary conditions and mesh recipes through to solver setup and post-processing.
They tend to get less readable as they get more complex though, so I recommend starting out simple. Start with familiar pattern matches, like asterisks, to avoid having to spell things out in full – "car-.*"
Pro Tip: Keep your regex simple & use extra naming conventions to do more complex stuff 👍
Why name stuff?
There are four main reasons that you might want to name something in a CFD model:
to apply a specific boundary condition
Almost everyone uses this, but not always consistently. Being able to replace umpteen dictionary entries with a single regular expression is a major time saver. It also reduces the chance you’ll miss something when you add or change boundaries.
to mesh it differently
Named input geometry is the key to unlocking the power of snappyHexMesh , especially when it comes to automated workflows. A strong naming convention makes it easy to apply consistent meshing strategies across multiple input geometries. Things like which surfaces should get extra refinement, or where to add/remove layers etc.
to identify it for reporting
If you want to monitor/report the forces on the front left brake duct then it’s much easier if it has a name. Same applies if you want to combine several surfaces into a single monitor/report using a regular expression.
to post-process it differently
Being able to easily select/exclude a subset of your model, can be both a time-saver and improve your output. Particularly useful for large/complex models &/or where the region of interest is relatively small.
Just enough naming
That being said, you don’t have to go crazy naming everything – if it doesn’t fall into one of these four categories, then I typically don’t give it a special name.
The motorBike tutorial has 60+ named bike boundaries that aren’t used for anything 😯
Design your own
“Design” is probably too strong, “evolve” might be a better choice.
Start with the above four reasons in mind, then add a prefix here & a suffix there to capture some of your modelling logic.
What makes this surface different from the others? What’s special about it & how can I identify it later? Try to find patterns & use them to inform your naming. Then tweak as required.
My goal is a naming convention that reduces the number of dictionary edits required to do my next run (this dovetails nicely with templating your cases).
Make sure you consider all four reasons though – I’ve seen plenty of naming conventions that make one of the CFD phases easier (typically meshing) only to make the rest of them much harder.
Where to name stuff
If you can name your surfaces in CAD and then carry those names through snappyHexMesh into your CFD model then awesome. Job done.
If your CAD package exports surfaces as part001, part002 etc then we have a bit of a problem (this is often the most troublesome phase when I’m helping clients adopt snappyHexMesh & OpenFOAM).
There are other naming options, but they’re often an order of magnitude more work than exporting them from CAD.
You can do it in FreeCAD. You can do it in a text editor. You can do some renaming with snappyHexMesh. You can rename bits after meshing with createPatch. You could even use patchGroups for some boundary condition/post-pro stuff.
Your choice will depend on the complexity of your models, but let me know if this is something you’re struggling with though.
Is it worth it?
Naming things can be difficult – both technically & philosophically – but haphazard naming can be the source of so many errors & so much wasted time that I think it’s well worth the effort to evolve your own naming convention.
How do you do yours? Do you have a formal naming convention? Are you a regex master? Or are you struggling to get named surfaces out of CAD?
Should I dedicate an issue to “how to name surfaces if your CAD package won’t do it” with tips for using some of the options I mentioned earlier, FreeCAD etc?
Let me know your thoughts & if you’d be interested my following this up in future issues. My inbox is always open.
Until next week, stay safe,
