This is Gimlet, a rewrite of Casey Stark's Nyx post-processing suite of the
same name. In its original form, Gimlet was a disk-based post-processing tool;
it converted BoxLib plot files into a custom HDF5 format, and then ran a series
of algorithms on this new file to generate a set of highly reduced data such as
probability distribution functions and power spectra.

In its new form, Gimlet now does all post-processing while the data resides in
memory, obviating the need for HDF5 (or even for saving the plot files at all).
It operates on standard BoxLib data structures: MultiFab, Geometry, etc.
Furthermore, Gimlet can run as part of an arbitrarily complex workflow which
executes either in situ or in-transit. When running in situ, all MPI processes
which are evolving the simulation stop and run Gimlet together before
continuing on. When running in-transit, we spawn a disjoint set of MPI
processes ("sidecars") which receive the data and post-process asynchronously
with respect to the "compute" group of MPI processes, which continue with
simulation evolution as soon as they have sent the necessary data to the
sidecars. Both in situ and in-transit approaches have advantages and
disadvantages, which are discussed in [1].

Gimlet calculates a variety of quantities:
 - optical depths along 1-D pencils aligned parallel to all 3 axes
 - 1-D line-of-sight power spectra P(k) along pencils
 - 3-D power spectra P(k,mu)
 - probability distribution functions of different fields (optical depths,
   fluxes, density, temperature, etc.)
 - Lyman-alpha fluxes

[1] Friesen, B., et al. "In situ and in-transit analysis of cosmological
    simulations." Computational Astrophysics and Cosmology. DOI:
    10.1186/s40668-016-0017-2