How to use patchGroups (& why)

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,