Implement the CosmicRayElectronDensity base Field

[luizfelippesr]

This should represent cosmic ray electron density at different energies.

The basic idea is to be able to return a 4-array: the first 3 axes for the coordinate grid, and the last one for energy bins.

Choice of energy bins

The difficulty, however, is what is the choice of energy bins and how to communicate this to the simulator in a nice way.

Currently, the Simulator does not have direct access to the field objects, only to the data produced by them. This was chosen to be this way on purpose: keeping the details of fields hidden from simulators reduces the chances of simulators requesting too specialised fields, preserving this way the future modularity.

In my view the two simplest solutions are the following.

1. Different spectral binning = different Field If there are only a few standard choices for the CR spectrum, one could have a different base field for each of them.
   • This would require no change in the present infrastructure
   • Multiple compatible CR Fields could be summed-up in usual way
   • Some simulators could be limited to specific choices of binning
   • Oddly, different choices of binning would have to be associated with different field_type strings.
2. Return (array, bin_array) Instead of returning an array, the get_data() method associated with CR Fields could return a tuple or list containing the 4-array and an extra array with the binning information
   • The Simulator base class will need to deal with this!
   • Only array's with common bin_array should be summed-up
   • If multiple bin_arrays are detected by the Simulator prepare_fields method, we need to choose how it will behave. Some possibilities:
     a. The Simulator raises an exception (only one choice of CR binning is allowed)
     b. Instead of saving an array to self.fields[field.field_type], one could save a dictionary with tuples of bin edges as keys.

Flux versus density

Another question that needs to be addressed before implementing the CR field is whether we would like to model the flux or simply a density.

If we were really modelling a flux, instead of a 4-array, we would need a 5-array, with an extra axis for the 3 components of the flux. Nevertheless, usually the CR flux is (to a good approximation) assumed to be isotropic, so we could just work with a density instead. This may, perhaps, be different if we want to include a UHECR "detector" simulator, but in this case a separate CosmicRayElectronFlux could be added.

Units

Despite the usual assumption of isotropy, the usual units for CR distribution are: (GeV m^2 s Sr)^{-1}, i.e. a flux. The conversion to a differential density distribution involves multiplying by 4 pi (i.e. assuming isotropy) and m_e/v, where v=beta*c is the velocity associated with CRs in that energy bin. A more physical choice of standard units would be simply cm^-3 erg^-1.

Regardless of the choice of units, we must include a tool to convert between the two options to facilitate later development for the user.

A related point is the choice of units and spacing for the spectrum. The most common approach is to have logarithmic bins in particle energy. Alternatively, one could have bins of relativistic gamma. I suspect, however, that the first option is both more convenient and common.