Visualisation and output

Table of Contents

• Visualise the patch files
• Solution output
  • Plot descriptive variable names
  • Output filters
  • Output directory
  • Multiscale data
• Solver-specific rendering recommendations
  • Finite Volumes
  • Discontinuous Galerkin
• Logging

ExaHyPE 2 relies on Peano's standard output routines to write file dumps, and it employs Peano's standard terminal routines to dump runtime information.

Further to that, you can enable Peano's statistics if you require more in-depth (profile) information.

Visualise the patch files

Consult Peano's generic discussion of various visualisation pathways as well as the patch file format.

Solution output

As the files can be rather large, the simulation configuration allows you to specify exactly how often you want to see file dumps, and you can also add spatial filters. The latter help you to visualise only subdomains. As we rely on Peano's infrastructure, you can use the scripts from Visualisation to convert the output files into vtu files.

By default, ExaHyPE dumps all data as one large vector Q per Finite Volume/integration point, i.e. you get a set of scalars. It also dumps all the resolution levels of the grid simultaneously. Therefore, one of the first postprocessing steps usually is to remove all data from the output data set besides the fine grid level.

Plot descriptive variable names

You can add a plot description to each solver which allows us to render more descriptive variable names:

my_solver.plot_description = "density, velocity_x, velocity_y, energy"

Output filters

By default, ExaHyPE maps each Finite Volume and each DG quadrature point onto a vertex in the output file, i.e., it maps the compute mesh onto an unstructured (visualisation) mesh. This can result in large data dumps.

Peano follows the philosophy that postprocessing should be done by postprocessing tools. While Peano's render script provides a filter such that you see only the patch or cell average, each dump of the whole simulation data might already be too heavy for many applications. Therefore, you can add filters. They restrict the memory footprint a priori. A further obvious strategy to bring the memory footprint down is to print less often.

Filters can be added to your setup via

probe_point = [0,0.693,0]
project.add_plot_filter( probe_point,[0.0,0.0,0.0],1 )
project.add_plot_filter( offset,size,10 )

The example above sets a probe, i.e. every plot step only the patch data around the probe is dumped. Every 10 snapshot steps however, the whole domain is written. I assume that offset and size are configured accordingly.

Further to the filters, each solver has an attribute select_dofs_to_print. It is set to None` by default which means that all quantities per degree of freedom are dumped into the output. You can pick only a few entries though via

my_solver.select_dofs_to_print = [4,5,8]

Output directory

The command

project.set_output_path( "/scratch/myfolder" )

configures Peano with a proper output path. Without this command, all output data is written to the working path.

Multiscale data

All Peano 4 output files dump various resolutions of the data. ExaHyPE 2 atm however does only use the finest mesh resolution to compute something. The coarser levels hence hold garbage. I therefore strongly recommend that you always run the render script with the option -filter-fine-grid. This makes the script throw away all coarser resolutions.

Solver-specific rendering recommendations

Finite Volumes

If you dump Finite Volume data, it becomes difficult to spot how the resulting Finite Volumes are organised in patches: The organisation in patches is not visible unless you study AMR resolution boundaries. If you are interested in seeing the patch boundaries, use the --shrink-cells option and pass in a value that is smaller than one. You then will see gaps (voids) between the individual patches.

Discontinuous Galerkin

If you use ExaHyPE's Discontinuous Galerkin solvers with non-Lobatto nodes, the file dumps will look pretty ragged. This is due to the fact that the DG quadrature points are not placed on the cell faces. This might be unsatisfying and make some postprocessing (isolines, e.g.) difficult, but we found it important to display the actual spatial arrangement of the unknowns.

The standard postprocessing scripts allow you to rescale individual cells. Use --shrink-cells with a value slightly bigger than one to spread out the quadrature points. It is important to note that the shrinking distorts the actual physical layout of the quadrature points, i.e.~the output will not really reflect the solution anymore. Alternatively, you can averaging over cells and display only the average. Consult the script's help.

Logging

ExaHyPE searches for a text file exahype.log-filter in the working directory. If no such file is found (or the file is corrupted), then it will use some default filter rules, i.e. dump the information to the terminal that I consider to be most important. If you want to adopt the output, I strongly recommend that you add a log filter configuration file.

Often, users are only interested in a particular phase of the simulation or want to specify different log entries per program phase. The program phases offered by default are

• create-grid-but-postpone-refinement
• create-grid
• create-grid-and-converge-load-balancing
• init-grid
• plot-solution
• time-step

The syntax of log filter files is discussed in the generic logging documentation of Peano.