paraFoam vs builtin

Hey there,

It’s Robin from CFD Engine and whilst not American, I am thankful to be in your inbox 🙏 This week’s note is driven by my own curiosity – am I missing out by not using paraFoam?

My gut feel is no, but let’s see…

A bit of background

Let me catch you up, just in case you’ve never used ParaView (it’s awesome by the way – you should take it for a spin).

ParaView (the super-capable, open-source post-processor) can read OpenFOAM data directly – no need to export to an intermediate file format.

In fact, you have two OpenFOAM readers to choose from – a plugin maintained by the OpenFOAM Foundation and another one maintained by Kitware (the makers of ParaView).

In true OpenFOAM fashion, they’re similar but different and don’t have a great way to differentiate them, let’s just call them:

• paraFoam – not the actual name of the Foundation plugin, but rather the command used to launch it. It reads files ending in .OpenFOAM & is only available in the ParaView versions that ship with the Foundation release (unless you want to compile it yourself).
• builtin – the Kitware plugin. It reads files ending in .foam & is available in all ParaView versions.

paraFoam or builtin ?

I don’t use paraFoam – I never have.

In the olden days, foamToVTK was your best bet for getting data into ParaView. Export your case, wrestle with the clunky parallel output and (eventually) visualise it in ParaView.

Now I just use the builtin reader that ships with the Kitware binaries.

When clients ask me about paraFoam my recommendation is to “use the builtin reader instead.” But what if I’m missing out by not using paraFoam? Worse, what if my clients are missing out (or I’m making their lives harder) by steering them away from paraFoam? 😰

So, I took both readers for a spin and, whilst there was no clear winner, it turns out that I am missing out on some nice features, but they come with a big downside.

If you always use paraFoam, you can take the builtin reader for a test drive by using touch open.foam to make an empty file in your case directory & read that file directly into ParaView.

The Headlines

To avoid burying the lede, the biggest difference (in my opinion) is that paraFoam can only read serial/reconstructed cases. The builtin reader can read serial or parallel/decomposed cases – a big upside in my workflow.

Beyond that, here are my notes on what’s the same & what’s different…

Common

• Both read serial/reconstructed cases
• Both create point data automatically (can be switched off)
• Both have option to skip Time=0 data
• Both read cellZones, but differently…
  • paraFoam adds the zones to the selection window, for you to select (or not) as you wish.
  • builtin doesn’t let you select which zones to read. If you ask for zones you get them all. You can use the extract block filter afterwards, to grab the zones of interest.
• Both will extrapolate data to patches (useful for when you want your surface velocity contours to be more than just zero).
  • You can switch it on & off in the paraFoam reader.
  • On by default in the builtin reader with no option to switch it off.

paraFoam plugin

• Has a blockMesh reader that enumerates the vertices/points of your various blocks. My blockMesh are usually super-simple, but I’ve still managed to get them into a knot in the past. I could see this being a useful feature (occasionally).
• Can read patchGroups and sets – nice to have, although perhaps not something you’d use everyday (I prefer a decent naming convention and regex over patchGroups, but both work).
• Includes the patch type alongside its name in the selector – a nice way to check which patches are walls, symmetry, groups etc.
• Has the option to show patch names, overlaid on your geometry. It’s kind of nice, but it gets messy quickly – not that useful.

builtin plugin

• Can read parallel/decomposed cases, no reconstruction required.
• Control over whether complex polyhedra are decomposed into something more VTK-friendly or left “as-written” (paraFoam does something similar, but not quite).

Gotchas

• The readers are implemented as plugins so, if you’re using ParaView in client-server mode, you need the plugin on the client and on the server.
• Both readers can read Lagrangian data with a caveat. The .com & .org OpenFOAM releases have different ways of recording particle data (the word of the day is barycentric). Therefore builtin will only read Lagrangian data from .com simulations & paraFoam will only read it from .org simulations. Confused yet?

Six of one…

To be honest I couldn’t crown a winner, you can do whatever you need to do, with whichever version you have, it’s just that the steps will vary.

Personally I’ll continue to recommend the builtin reader. I like to be able to choose my ParaView version independent of my OpenFOAM version (not of fan of them being bundled together in the Foundation release).

Plus, I really like being able to read decomposed/parallel cases – that’s my killer feature.

But, if I had complex blockMesh recipes, if I used sets/groups/zones extensively or if I ran Lagrangian simulations in the Foundation version then I’d probably change my mind.

Which reader do you use? Do you use both (for different tasks) or do you just stick to one? Maybe you import data via another file format (Ensight, VTK etc)? Perhaps you’re not on the ParaView-train at all – in that case, which post-processor do you use? Really keen to hear what I’m missing out on – drop me a note.

Until next week, please post-process responsibly,