Hey there,
It’s Robin from CFD Engine, closing out a busy week of actual CF-Do-ing – I was surprised that I could remember how to do it 😉
So, after a week of wrestling snappyHexMesh and untangling boundary conditions, I thought I’d write about post-pro as a break.
When I talked about doing everything on the cluster I mentioned exporting “post-pro assets” as opposed to creating them in ParaView.
It’s not ground-breaking stuff (it’s in the motorBike tutorial for example) but I don’t know if everyone does it this way, so I thought I’d elaborate on it a little bit.
If this is one of those emails where you already know all of it, then I thank you for your patience. If not, then I hope it’s useful. Either way, it sets up some context for future deep-dives.
Same old, same old
My CFD looks pretty similar day-to-day. Even as a consultant, I tend to stay in my lane. No accidentally straying into weather forecasting one day or naval architecture the next, not me.
My CFD needs aren’t exotic, and neither is my post-processing. It would be nice if life was full of custom, photo-realistic renders of race cars with colourful wakes. Unfortunately, most days look a lot less exciting than that.
I’m most likely to be found making surface contours plots and sweeping planes through the fluid. Maybe I’ll check out the occasional isosurface, or trace a few streamlines to find out where flow came from (or went). Perhaps a bit of LIC (line integral convolution) if I’m feeling snazzy. That’s about it.
Why export?
I could do all of the above in ParaView. The built-in OpenFOAM reader works great & there are filters for all the surfaces/slices/streamlines you could ever need.
Model size isn’t a problem either – ParaView can handle BIG models, much bigger than I’m ever likely to throw at it.
So, why bother exporting?
In short – speed & size.
ParaView flies when it’s processing the lightweight assets exported from OpenFOAM. Plus they’re easily/cheaply archived for future use & quickly downloaded, should they be needed back at base.
What, Where & How?
There are essentially three steps to this process – average some fields, create some new fields & export stuff. Most of the heavy-lifting is done by the postProcess utility with its numerous libraries & functions. And it all runs in parallel, on the cluster, no reconstruction steps required.
Average some fields
I use fieldAverage to (wait for it) average some fields at the tail end of my simulations. I’ll typically average U & p over the last 500 iterations and then average the forces over that same period. It helps the forces & plots to tell the same story.
Create new fields
Next up, I’ll create a few new fields that weren’t stored as part of the simulation. Using the averaged U & p fields, I’ll export near-wall velocity plus total & static pressure coefficients.
There are lots of other fields you could export, for example Lambda2 & Q for all you vortex chasers. Try postProcess -list for more.
It’s great functionality, but watch out for the interesting new field names – total(pMean)_coeff – really? 😬
Export Slices, Surfaces & Isosurfaces
I use the surfaces function in postProcess to extract everything surface-y – fluid slices, model surfaces & isosurfaces. I’ve had problems in the past with exports failing as I think they ran out of memory. It might not be the case anymore but, to err on the side of caution, I split the exports across a few dictionaries & run it multiple times (it’s usually pretty quick).
One nice touch with this function, is that the exported assets are serial, i.e. reconstructed, without you having to actually reconstruct the full case. Sounds obvious but, if you ever wrestled partitioned foamToVTK output in the olden days, you’ll really appreciate this 🙏
Export Streamlines
I don’t use streamlines that often but, when I need to trace flow into an inlet or cooling duct for example, I’ll use the streamline function.
If I want to get precise about the streamline start points then I’ll build a low-res OBJ file in CAD and reference it as the seeding method. Ideal for releasing a grid of streamlines.
I’m starting to use wallBoundedStreamlines more and more often. They do a really nice job of approximating oilflow, much clearer (in my opinion) than LIC plots.
I use the patches themselves as the seed points, restrict the number of points to a few thousand (some trial & error required here), use the “near-wall-U-mean” field from earlier & track the streams both forwards & backwards.
They look great plotted in a solid colour (black) overlaid on contours of near-wall velocity – plus there’s no mess to clean up, unlike “real” oilflow.
Anything else?
This is just an overview – there’s much more effort required to make it all work. And now that I’ve written it all down, it probably comes across as a bit too much hassle. Perhaps I should just do it all in ParaView 🤔
I still think it’s all worthwhile though, especially for “big” models (whatever that means these days). But, I could see how you might happily skip these steps if you had a nice small model. Your Mileage May Vary.
Do you do something along these lines? Or is it overkill? How do you do yours? Any good tricks I’m missing out on? Is there anything post-pro-related that you’re struggling with? Let me know, my inbox is always open.
Until next week, CFD safely,
