One common task that is not easy in ET is to create simple one-dimensional histograms from grid variables. There should be support for this in the core infrastructure. Writing user thorns for this task requires the use of internal implementation details such as the Carpet weight mask. This also ties such code to Carpet and prevents use with e.g. CarpetX. Further, there needs to be a standard to save such histograms to disk at regular timesteps, much like the grid data itself.
- There should be a histogram API that allows creating histograms, very much like 1D arrays. The IO thorns should write those to disk at user specified timesteps, similarly as done for arrays. In addition to the bins, there should be two special bins for values above and below the bin range. Metadata that needs to be saved as well is the binning (lower bound, upper bound, number of bins). Specifying histograms should be possible via parfile, populating them should be possible for user code via function calls.
- There should be a thorn that allows to create arbitrarily many histograms, each from two grid variables, one used for binning, and one for the weight. The weight should be a density with respect to coordinate volume. The cell size and weights from refinement masks should be handled by the thorn, not the user.
A histogram of ejecta velocities in BNS merger simulations. This requires a one-dimensional histogram at a given timestep, where the bins correspond to velocity. The baryonic mass in each cell then needs to be added in the bin given by the velocity in the same cell. All the user would have to do is write a thorn that sets up two scalar grid variables, one with unbound mass density (per coordinate volume) and one with the velocity.
Another thorn might use a different approach for measuring the same, computing fluxes through a surface instead. Such a thorn could then still use the histogram API directly to get standardized file IO of those histograms.
A BNS tracking thorn may employ two histograms of masses binned by phi-position and radial coordinate, respectively, to determine orbital phase and separation without resorting to fragile code that resorts to reduction operations.