Hey there,
It’s Robin from CFD Engine & I’ve noticed myself using a new phrase when I’m talking about one of my favourite aspects of working with OpenFOAM.
It’s become a useful shorthand for me, but it would probably benefit from some explaining:
“What is OpenFOAM thinking?”
I’m always on the lookout for people doing interesting things with OpenFOAM & although I’m impressed by people who can code new things, I have a particular affinity for people who take existing features & string them together to produce innovative workflows & capabilities.
This is the heart of “OpenFOAM Thinking.”
Unix people have the Unix Philosophy – a bias towards creating software tools that are minimal, modular & composable – they do a specific task, do it well & play nicely with each other.
I think it applies pretty well to OpenFOAM, and it’s the last bit – the composablility (that they play nicely together) that let’s the magic happen.
I liken it to building something from Lego – you can build a wide variety of things from a relatively limited set of blocks. Some of those things are neat, some are a bit lumpy & misshapen, some are downright ugly, but some stop you in your tracks thinking “wow, I did not know you could do that with Lego.”
Being able to take the “building blocks” that make up OpenFOAM and use them to build something innovative, useful and that elicits a “I wish I’d thought of that” response from others, is a great skill to cultivate.
By cultivate, I mean it’s something you have to work at. Knowing what the individual tools do is essential, but taking the time to play with them, coaxing them into solving new problems, is always time well spent.
That’s what I’m trying to get at with “OpenFOAM Thinking.”
Examples
This kind of play can easily get messy and it can also get complicated – it’s enough to put you off ever trying to do something new.
Occasionally you’ll cross paths with someone else’s “OpenFOAM Thinking” & when you do, it’s worth paying attention. Dig in, figure out how they made it work, how they put it together & how you could do it better.
DrivAer Tutorial
Examples abound in the OpenFOAM tutorials – the new DrivAer tutorial in OpenFOAM v9 is a great one, with it’s neat Allrun script that lets you change model size & the number of cores at run time, all done within a bash script.
AirShaper Mesh Refinement
If you fancy giving your OpenFOAM Thinking a workout, then dig into the the GitHub repository that AirShaper recently released.
It’s a workflow for doing solution-adaptive mesh refinement that includes using snappyHexMesh snap the refined mesh back onto the original surface. Check out the blog post for more info.
Their method uses standard OpenFOAM utilities & strings them together in clever way to do something that isn’t usually possible in OpenFOAM.
Neat – but complicated – thankfully there’s some documentation that walks you through what’s going on.
Worth a look, even if you don’t do this kind of refinement.
Jugaad
Exercises in “OpenFOAM Thinking” are usually rough around the edges, complicated & brittle. But they often get the job done and give us a peak at what a more polished version might look like & how it might work. It’s jugaad & I like it.
Do you have an example of some “OpenFOAM Thinking” that you’ve come across or developed yourself?
Or is there something you’d like to be able to do (perhaps something you used to do in a different code) that’s proving difficult to piece together in OpenFOAM?
Drop me a note & fill me in, I’m always keen to hear tales of “OpenFOAM Thinking” or to help out if I can.
Until next week, stay safe,
