Hey there,
It’s Robin from CFD Engine & I’m going deep into the OpenFOAM weeds this week for some “fun” with decomposePar & zero directories.
It’s tricky to write these types of emails, to keep them from descending into a brain-melting stream of OpenFOAMery. But when I find out a tool I use every day, doesn’t quite work the way I thought it did, then I have to share it.
Let me try to explain…
A bit of background
My typical simulations go something like this:
blockMesh > decomposePar > snappyHexMesh (in parallel) > manually copy the initial conditions to the processors > solve > celebrate 🎉
But decomposePar is happy to handle fields – so why not let it handle my initial conditions & go straight from snappyHexMesh to solve?
Short version: You can’t. See you next week 👋
Longer version: You can (kind of), but here’s what you need to know…
When you decompose your blockMesh, decomposePar will (by default) take your zero directory & decompose that too – each processor will end up with a portion of mesh and a 0 directory 👍
But (the bit I didn’t know) is that decomposePar does some processing on that zero directory. So if you use any wildcards to pattern-match boundaries, if you use #include directives to reference other files, or if you do some maths using expressions, then these all get parsed & expanded by decomposePar, with the results written to your new zero directories.
All good, right?
Kind of, the simple implications of this are:
- all of the lovely boundaries you’re about to create in
snappyHexMeshwon’t be present in your processor’s zero directories (they’ll only include the boundaries thatdecomposeParfound in yourblockMesh) & it won’t solve; - if you store some of your flow parameters in separate files (windspeed, pressure, turbulence values etc) &
#includea reference to them in your initial conditions, then they will have been parsed & expanded. Subsequent changes to those#included files will have no effect.
Not ideal.
Your Options
If (like me) you want to run decomposePar just once and have it handle your zero directories, then you can use decomposePar -copyZero instead.
As the name suggests, this does all of the usual mesh decomposition & then copies your zero directory to each processor without parsing the contents. All of your includes, wildcards, expressions etc will be intact & you can go straight from snappyHexMesh -overwrite to your solver of choice.
If you want to distribute your zero directories after meshing in parallel, you can use decomposePar -fields -copyZero instead. It doesn’t do any geometry decomposition, but copies your zero directory into each existing processor.
Be careful with this one though – if a processor already has a zero directory, then this will copy your zero directory into it (processor0/0/0/...) probably not what you wanted.
The restore0Dir command, mentioned in the last “Tiny Tips” issue, could do a job here too.
But if all else fails, you could break out the unix commands. In which case be prepared to accidentally delete your mesh (at least once) while figuring out which commands to use.
Let me know if I should do a future issue on unix commands for case management type stuff.
Confused?
I hope that made some sense? In short, decomposePar does more than I’d thought & has a few options that can help when working with zero directories.
OpenFOAM has so much depth that these things pop up periodically. You thought you understood how a tool worked & then you find something new – every day is a school day.
Do you have any similar examples which I can share with the class? Drop me a note & fill me in.
Until next week, stay safe,
