Measure the performance numbers of the article, and build its table

[gouarin]

The three numbers the tables of the article are made of, measured by the solver
instead of reconstructed from a log, and the script that turns them into the
table.

What is measured

euler/metrics.hpp, wired into the three binaries:

sparsity index	cells of the adapted mesh over the cells of the uniform mesh at --max-level, at the initial and at the final time. A Riemann problem fills its mesh up as the waves spread, and one number taken at one end would flatter or damn it.
cell updates, Mcu/s	one cell advanced by one time step, counted once per cell per step whatever the integrator does inside — otherwise Strang's 2*dim - 1 sweeps would read as more work done.
time to solution	the time loop. The adaptation is in it and is reported apart; writing files is not, --nfiles being a choice of whoever runs the solver.

Reduced over the ranks once, in a collective call: cells and updates summed,
times taken at their maximum. --metrics-file writes the same numbers as JSON.

The table

python python/performance.py --levels 6 7 8 9 --uniform, on configuration 3
of Lax & Liu to t_f = 0.8 at second order, one core:

 l_min  l_max   resolution    mr-eps    Mcu/s  time (s)    AMR           cells ti/tf    sparsity ti/tf
     3      6         64^2   default      2.2      0.39  25.1%           1720 / 3784     42.0% / 92.4%
     3      7        128^2   default      2.4      2.49  29.6%          3916 / 13522     23.9% / 82.5%
     3      8        256^2   default      2.5     15.41  28.1%          8416 / 45394     12.8% / 69.3%
     3      9        512^2   default      2.5    102.92  28.4%        17524 / 151480      6.7% / 57.8%
     9      9        512^2   default      4.7    147.64   0.0%       262144 / 262144   100.0% / 100.0%

The last row is the uniform mesh at the same resolution, the reference the
article puts at the bottom of its own table: the adapted run does 2.7 times
fewer cell updates and is 1.4 times faster, running at a little more than half
the throughput of the uniform one. About a third of what is lost is the
adaptation itself; the rest is what a cell of an adapted mesh costs.

--mr-eps takes several values and measures each. At level 9, two decades of
threshold take the final sparsity from 58% to 16% and the time to solution from
115 s to 59 s, with the initial mesh unmoved — the details of a piecewise
constant state are of order one at a discontinuity, far above every threshold in
that range. Those rows say nothing about accuracy, which is what
python/error_analysis.py measures.

Reading it against the article

The readme says it at length, and the short version is that the sparsity column
is where the comparison goes wrong most easily. What the multiresolution keeps
is a neighbourhood of the discontinuities, which are curves in a plane, so their
share of the mesh falls with the resolution: 92%, 83%, 69%, 58% over the four
rows. A sparsity index quoted without the max-level it was measured at compares
nothing.

Tests

Held against what the run computed, not against themselves: 100% sparsity on a
uniform mesh whose cell count is arithmetic on a unit domain, final cell count
equal to the cell count of the HDF5 file the run wrote, time to solution holding
the adaptation and not the output. One slow test holds the fall of the sparsity
index with the resolution.

136 fast tests, 23 slow.