Peano
Loading...
Searching...
No Matches
Probing data files

probe.py reads out the unknowns at one point of a Peano patch file over time and writes them into a csv file.

It is the counterpart of render.py (Offline (command-line) conversation into VTK file formats): it accepts the same meta files and snapshot options, but instead of whole VTU files, it yields one time series. The script does not rely on ParaView/pvpython or vtk.

python3 src/tarch/plotter/api/probe.py --point 0.3 0.6 0.1 -o probe.csv solution.peano-patch-file
This file is part of the load balancing project within Peano 4.
Definition __init__.py:1
-single-black-hole
Have to include this header, as I need access to the SYCL_EXTERNAL keyword.
Definition accelerator.h:19

The csv file holds one row per snapshot, sorted by time. The first column is the snapshot's time stamp, followed by all unknowns of all data sets within the file. If the description of a data set lists one name per unknown, e.g. description h, hu, the columns carry these names. ExaHyPE's solvers write such descriptions if you give their variables names. If two data sets use the same name, the columns are prefixed with the data set, e.g. SWEQ_h. Otherwise, the columns are named after the data set and the index of the unknown, e.g.

time,solution_0,solution_1
0.0,1.0,0.25
0.1,1.02,0.24

The postprocessing tutorial shows the probe with named unknowns.

The most important options are

  • –point x y [z] The probe point. For 2d data, any z coordinate is ignored.
  • -o/–output Name of the csv file (default probe.csv).
  • –set-identifier Probe only one data set from the patch file.
  • -s The input file is a single snapshot rather than a meta file. Its time stamp is then 0.
  • -start/-end Restrict the probing to a range of snapshots.
  • -j Number of worker processes probing the snapshots in parallel.

Which value do we pick?

There is no interpolation. Among all patches that contain the point, we take the finest one, i.e. coarser levels of an adaptive mesh are ignored if they are dumped, too. If the point sits exactly on a face between two patches, we take the patch to the right/top/front. Within the patch, we take

  • for cell data, the value of the (sub)cell that contains the point;
  • for vertex data, the value of the dof which is nearest to the point. This takes the mapping of the patch file into account, i.e. works for non-equidistant dof layouts such as Gauss-Lobatto points, too.

Cell data with a non-default mapping is not supported. If no patch in a snapshot contains the point, the script writes NaN and issues a warning.

Performance

The script parses only the offset and size of each patch and skips the values of all patches that do not contain the point. It therefore is considerably cheaper than a conversion into VTU. The I/O remains the same though, i.e. each snapshot file is still read once.