Support for creating and saving 1D histograms

Create issue
Issue #2542 new
Wolfgang Kastaun created an issue

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.


  1. 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.
  2. 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.

Example applications:

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.

Comments (2)

  1. Roland Haas

    Instead of just offering a signle type of reduction (historgram) it might be nicer (and not more work) to allow users to supply a custom “kernel” that is being called for each grid point by CarpetReduce. Something like:

    int callback(cGH* cctkGH, CCTK_INT idx, CCTK_REAL data, void *calldata)

    or so which would let users implement their own histogram or other reductions, eg. a maximum location reduction.

  2. Wolfgang Kastaun reporter

    Such a low level kernel may be a good building block for implementing the histograms, but is only addressing part of the problem. The callback function could store histograms of local data, but this still has to be reduced globally at some point. When exactly to schedule the reduction and the resetting of the histograms between timesteps will then probably become another dark art (scheduling GLOBAL-LATE or GLOBAL-EARLY and what bin?). It also does not handle output in a standard format, nor the basic histogram code. In short, I think histograms are such a basic feature that they should be very easy to create for the user, similar to scalar reductions.

  3. Log in to comment