5 reasons we love OpenFOAM

How open are you about the tools you use?

I’ve always been pretty guarded about what software & hardware we use. Some of the secret sauce lives in these software & hardware stacks. I didn’t want to give too much away. But with the switch to a focus on CFD consulting I’ve come to the conclusion that the secret sauce isn’t in the software or hardware. It’s in how they’re knitted together to deliver the goods.

Maybe it wouldn’t hurt to be a little more open with the tools I use everyday? So, in the spirit of openness, I’m starting with the question I get asked the most about software — “what CFD code do you use?”

No prizes for guessing it’s OpenFOAM, but here are five reasons why I reckon it’s the bees knees. I’m sure at least 3 of these will be the reasons others can’t get to grips with it — different strokes for different folks.

I’ll call this out right now, before we go any further. CFD Engine has absolutely no affiliation with OpenFOAM nor are we endorsed or approved by any of the increasing number of OpenFOAM players¹. We couldn’t function as a business without it though — so we owe it a debt of gratitude at least.

Onward to the list & in no particular order:

1. GNU General Public License

OpenFOAM, as the name suggests, is open-source. It’s made freely-available by the OpenFOAM Foundation under the GNU Public License (GPL). You will have tripped over open-source software on your travels around the internets, whether you know what it is or not. The open-source license in question here, the GPL, is the same as used by WordPress which powers almost a quarter of all websites. Not a niche software license then?

Leaving aside the freely-available bit for now, the fact that OpenFOAM is distributed under the GPL is a big deal for me.

Firstly, it provides a degree of security when it comes to developing a business around someone else’s software. Whilst there is no guarantee how the code will develop in the future — we’ll always have at least what we have now. We might never move forward, but at least the rug can’t be pulled from under me with what is a key component in the business.

Secondly, there is nothing in the GPL that says you can’t make money from GPL’d software. Take a look at WordPress themes & plugins if you want to see a thriving marketplace that is underpinned, not held back, by the GPL.

2. snappyHexMesh

In the life of the CFD mesh-monkey there are two time periods. There was “before snappyHexMesh” — all blocking structures, O-grids, popping slivers & high-aspect ratio pyramids. And now, “after snappyHexMesh” which is all hexahedral unicorns & rainbows.

But seriously, before snappyHexMesh, OpenFOAM really only fulfilled the solve role in the mesh-solve-postpro cycle. blockMesh was (and still is) only for the bravest-of-heart & simplest-of-geometry. So adding a very-capable hex mesher to the tool-set was enormous. Now you can loop the mesh-solve-postpro cycle to your heart’s content with only open-source tools (OpenFOAM & ParaView).

snappyHexMesh seems to get better with every release & without it our whole cloudy process would be in trouble. I haven’t tried out the new, and equally fantastically named, foamyHexMesh. But it tells me that the OpenFOAM Foundation are still pushing their meshing capability forwards. I’m looking forward to what they have in store next. What might it be able to do? But, more importantly, what it might be called?

3. Directory Structure

Have you felt the pain of having to wait 10mins to read in a mammoth, all-in-one sim file just to change a single number & then write it all out again 10 seconds later?

If so, then you should appreciate the “text files in a directory structure” approach used by OpenFOAM. The ability to access any setting with just a text editor (or for the braver CFD-ist, by firing-off sed -i) should come as a huge win to the sim file folks.

But that’s just about speed. How about adding in easy version control using git (or similar)? Or being able to diff files to spot tiny config changes? Or use git bisect to spot where config errors crept in? Or issuing a fix using patch. Or having full editing control with nothing more than a terminal session to a machine on the other side of the world — useful?

Which brings me nicely on to my next point…

4. No GUI

You don’t need a GUI.

Really, honestly — You don’t need a GUI.

Once you know your way around the directory structure & the config files, a GUI will slow you down. Yes, you want to be able to look at geometry & mesh & results but that’s where ParaView comes in.

If you really must have a GUI there seems to be an increasing number of them popping up. I’m sure some of them are even pretty good. I don’t use one & I definitely benefit from knowing which setting lives in which file & which folder to find it in.

Doesn’t it take almost as long to learn which button to press as which text file to look in?

5. Cost

So I left the whole freely-available thing to one side earlier. Let’s pick it up again here. I certainly can’t pretend the cost of OpenFOAM isn’t one of it’s major advantages.

However, just because it’s free to download & use, that doesn’t mean that it doesn’t have a cost. To most users this cost will be the time it takes to learn how to use it & the time taken to diagnose problems essentially without formal support. With commercial software you buy the code & the support is free. Whereas open-source codes are typically free to use, but you have to pay for timely support.

That being said, the business model of CFD Engine would be a lot different (i.e. not viable) if I had to buy commercial software to actually do any CFD.

More often than not the best tool for the job is the one you’re most comfortable with or the one you’ve got available. OpenFoam isn’t for everyone, but it is for me & there would be no CFD Engine without it.