Hey there,
It’s Robin from CFD Engine & if you’re creating post-pro images using pvbatch, then I’ve got three tips (in three minutes) that should help speed things up a bit.
Ranging from a simple VTP loading tweak, all the way up to rethinking how you approach your post-pro in the first place, these three options could turbocharge your image generation at no extra cost.
So, before you go building a bespoke post-pro machine, why not give these a try…
Caveat
I’m specifically talking about scripted, non-interactive post-pro here – the images that you produce for every single run that let you compare simulations quickly & easily.
I can’t help speed up the more interactive sessions where we’re poking around the solution, scratching our heads & trying to figure out what on earth is going on 😶 sorry.
To the tips…
Do less ParaView
This one sounds facetious, but it’s not – if you really want to reduce the time ParaView takes to produce your post-pro, then give it less work to do.
Instead of reading your whole case into ParaView (which can take a while) why not export all of your slices, surfaces, isosurfaces, streamlines etc direct from OpenFOAM?
The exports are generally quicker than doing the same operation in ParaView (especially with big cases), there’s (usually) no need to reconstruct your case & ParaView really flies when you feed it lightweight post-pro assets instead of a full case.
Which brings me to the next one…
Use Parallel
ParaView doesn’t need much memory to handle these little post-pro files (certainly not in comparison to loading a complete case) so why not try doing things in parallel?
I’m not talking about running one ParaView across lots of cores (you can do that) but rather, running several ParaView’s at the same time.
There are lots of ways to do it, but GNU Parallel is a good place to start, an open-source, command-line tool that’s built for exactly this task.
For example…
parallel --jobs 4 pvbatch ::: postScript*.py
…would work its way though all of the Python postScripts in the current directory, running (up to) 4 pvbatch jobs at a time 👍
It has lots of other neat features, but this simple one-liner could 4x your post-pro throughput on its own.
Check out their tropical cheat sheet for some more examples, or their online manpage, if you really want to dig in.
Time Array
Lastly, if you’re using VTP files to produce animations from steady-state data (like orbiting the camera around an object, for example) then this one could save you loads of time.
When you read a VTP file into ParaView, you might notice a Time Array option that’s set to TimeValue by default.
This has the undesirable effect of causing ParaView to reload the VTP file for each frame of an animation, a real waste if your data doesn’t change.
Switch it to None & ditch all of those reloads.
I have an animation that used to take 25mins to complete, changing this one setting reduced it to just 5mins 🤯 your mileage may vary.
Remember, you can always use Trace to reveal the equivalent Python command to add to your scripts – find it under Tools > Start Trace in ParaView.
More faster
There you have it – three tips for making your post-pro quicker, maybe even quick enough that you can run it on the cluster & avoid buying a dedicated post-pro machine.
As always, your returns will depend on the kind of post-pro you do, your model size & your hardware, but I reckon they’re worth a try at least.
There might be some good speed gains just waiting to be uncovered.
Of course, if you’ve got any other speed mods that you think I should check out, then drop me a note – my inbox is always open.
Until next week, stay safe,
