'%20d='M364.9%20143.2v98.9l-1.4%201.2-165.6%20140.4%2035.7%2029.7v-34.2l1.4-1.2%20123.4-105.4%206.5-5.6v37l-1.3%201.2-99.7%2085.8v84.7l-6.6-5.7-97-83.1-3.6-3%203.5-3%20174.4-150.6v-25.1L153.7%20360.5l-6.6%205.7v-98.9l1.4-1.2%20161.6-138-35.7-29.7v34.4L273%20134%20153.7%20236.7l-6.6%205.7v-37l1.3-1.2%2097-83.2V36.3L252%2042l97.1%2083.1%203.6%203-3.6%203-171.7%20147.7V304l106.2-90.6%2056.4-48.8%2018.3-15.7z'%20/%3e%3c/svg%3e)
A picture endsthe visualisation
It does not end the argument. Sooner or later somebody asks what the pressure was at the outlet, and a colour map cannot answer that.
Compare a simulated value against a measured one at the exact coordinate the sensor sat at.
A profile along a centreline or across a boundary layer says more than any single rendering.
A field that looks fine usually has one region where it is not. Probing finds it faster than looking.
A point, a line,a surface, a list
ParaView has one probe for each shape of question. Choosing the right one is most of the work.
Plot Over Linedoes most of it
Sampling along a straight line and plotting it is the probe that answers the largest share of real questions.
Give it two endpoints and a resolution, press Apply, and a Line Chart View opens beside the render view. Tick the arrays you want on the chart, and right-click to Save Data if you need the numbers as CSV. The line itself can be dragged in the 3D view once Show Line is on, which is faster than typing coordinates when you are still exploring.
The default is coarse. Sharp gradients need hundreds of samples, not the handful you get for free.
Show Line puts handles in the 3D view, which beats typing coordinates while you are still exploring.
Right-click the chart to write CSV, so the numbers end up in whatever you actually plot with.
Resolution is the one setting people leave alone and should not. The default samples sparsely; a boundary layer or a shock will be missed entirely at low resolution and appear as a gentle slope instead of the step it actually is.
Trace it once,then run it headless
Probing is the part of the workflow most worth automating, because you will be doing it once per timestep or once per case.
$ pvpython probe.py --case run-042
$ cat outlet.csv
Record the probing session with Tools · Start Trace, save it, and edit the resulting script into a loop over your cases. Run it with pvpython on the machine that holds the data rather than pulling gigabytes back to a laptop — the whole point of the data being on a rented machine is that the analysis can happen next to it.
ParaView isalready built
Nothing here needs compiling. Pick a machine, and these two commands put it on there.
$ dxflow workflow create --identity paraview hub://paraview
$ dxflow workflow start paraview