Magic Numbers

Here is a list of things that already exist. You should use these instead of inventing your own.

1. #include <cmath>
   This defines the value of pi using std::M_PI.
2. #include "CLHEP/Units/SystemOfUnits.h"
   This defines a system of base units and stores the constants needed to transform among different units. Both Geant4 and Mu2e have adopted this convention for base units. The set of base units is the same as for Geant4 and Mu2e.
3. #include "CLHEP/Units/PhysicalConstants.h"
   This defines many physical constants, such as the speed of light, charge of an electorn etc.
4. #include "MCDataProducts/inc/PDGCode.hh"
   This defines a big enum with symbolic names for most of the PDG particle codes.
5. There are many enum's defined in the Mu2e code. These include:
   • MCDataProducts/inc/GenId.hh
   • MCDataProducts/inc/ProcessCode.hh

When you need to define your own a constant, or other magic number, there are several places that it might make sense to define it. These include:

1. enums or static const variables in header files.
2. the conditions data system.
3. the geometry system (maybe someday this will be a subset of conditions data?)
4. run time parameters
5. constants written directly into files.

1. Enums or static const variables in header files
   This makes sense for things like pdg codes for various particles, enums to define which generator was used to produce a particular particle. Obviously this only makes sense for parameters that will never change their values over the course of the experiment.
2. The conditions data system
   This makes sense for any parameter that defines what the apparatus is, either the nominal design or the "as calibrated" values. It is NOT necessary that a parameter to be time dependent to be here. For example this would be a good place to store the rotation period of the debuncher ring.
3. The geometry system
   I suppose that this will someday be a subset of the conditions data system. Right now it is separate ( we needed geometry before we needed conditions data so the geometry was built first).
4. Run time parameters
   These are parameters specified in the module defintion in the .fcl file.
5. Constants written directly into files
   In the summer of 2009, Ivano Sarra digitized a plot of the photon energy spectrum from pi- capture on Al. He parameterized the data by fitting the data using a function with some free parameters. We are not likely to change the values of these parameters: so just hard code them in to the function and provide a reference where they came from. If we decide that these parameters need to be variable then they below as conditions data. (If we want to study systematics I think we will reweight MC events rather than change the function.)

An Example

1. The nominal (design value) of the start time of the live window, 700 ns.
2. The orbital period of the debuncher, 1694 ns.
3. The nominal end of the live window, which might or might not be the same as the orbital period of the debuncher.
4. The actual value of the start time for the actual DAQ on a particular run.
5. The actual value of the end of DAQ window for a particular run.
6. The start and end of the live window to be used by the event generators in a particular run of the MC.
7. The start and end of the live window to be used by the digitizer code in a particular run of the MC.

Security, Privacy, Legal