Hey there 👋
It’s Robin from CFD Engine & if your boundary names are a bit all over the place & your BC files are a mile long, then this might interest you.
patchGroups let you collect boundaries into named groups & use those groups to simplify your config files.
You can use them everywhere, from blockMesh to postProcess. You can even create ad-hoc groups for one-off tasks.
You might be using them right now without even realising.
Sound interesting?
Read on…
Why patchGroups?
There are four main reasons for naming stuff in OpenFOAM – to control the mesh, to apply a boundary condition, to identify it for reporting & to post-process it.
Incorporating all of those aspects into a single naming convention can be a bit tricky.
patchGroups help us cover all those bases by providing an extra level of naming flexibility.
Any place we can use a boundary name, we can also use a group name.
You might even have spotted some groups in the tutorials.
In the motorBike tutorial, the bike & rider are added to a motorBikeGroup via snappyHexMesh & that group is used to set the boundary conditions for all 67 named surfaces, with just a single entry (see this U file).
You could get the same effect using regular expressions (e.g. "motorBike.*") in the boundary condition files 🤔 but patchGroups come with a little bonus feature.
ParaView can read patchGroups directly from your OpenFOAM case – great for visually checking that your groups all correct.
Done-for-you patchGroups
Many OpenFOAM tools auto-generate patchGroups (based on boundary types) without you even asking.
For example, you might spot a wall group after you run blockMesh, or a processor group, or an empty group etc.
These done-for-you patchGroups are particularly useful for setting common boundary conditions, especially on simpler setups.
How to create a custom patchGroup
You could just open your constant/polyMesh/boundary file in a text editor & type out your groups 😬 but here’s how I tend to create them…
blockMesh
You can add the inGroups keyword to to any boundary in your blockMeshDict to associate it with a patchGroup.
This blockMeshDict snippet would place my-special-wall into grpOne & grpTwo (creating those groups if they didn’t already exist).
snappyHexMesh
I mentioned this earlier, but you can create patchGroups when you set your refinements in snappyHexMeshDict.
This refinementSurfaces snippet would add all of the patches from my-special-geom into grpOne (and set them all to wall as a bonus).
changeDictionary
If you want to create (or modify) patchGroups after meshing, then you can do it with changeDictionary.
Create a changeDictionaryDict file in your system directory that looks something like this…
This snippet would place all of the boundaries that match my-special.* into two groups: grpSpecial & wall.
wall is one of the auto-generated type groups. If the boundaries were already in the wall group & I didn’t include it in the list, changeDictionary would take them out & potentially mess up my boundary conditions – worth bearing in mind 🤔
Run the above snippet with changeDictionary (in parallel or serial) to create your groups.
You can use this approach to create a new group, to add boundaries to an existing group, to remove boundaries from a group or even empty/delete a group.
Top Tip: Use a prefix, suffix (or some other convention) to make it obvious, at a glance, that this name refers to a group, not just a boundary.
Double-check your new groups in ParaView, just to be sure it all worked 🤞
Over to you
patchGroups have been around for years, they’re in .com & .org releases, ParaView can read them natively (since v5.10) & they’re a neat way to add a little extra flexibility to your naming convention.
Give them a quick spin if you’ve not used them before. Make up a little blockMesh & try grouping / re-grouping the boundaries to see how it all works.
Let me know how you get on & how you’re using them in your workflow.
Until next week, stay safe,
