MagicNumbers

Introduction

This page is to encourage people to think about where to find and where to put the myriad magic numbers that we need to define the experiment and write the code.

Standard sources

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.
#include "CLHEP/Units/PhysicalConstants.h" This defines many physical constants, such as the speed of light, charge of an electorn etc.
#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.

Here are a few comments about each of these choices:

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

Consider the example of the live window of the experiment. There are many distinct ideas that we need to keep distinguishable and the code should make these distinctions. For the time being, all of the numbers below will either be 700 ns or 1694 ns, but we should keep them separate so that we can change them later.

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.

When I am writing MC, I give default values to 6) using 1) and 2). Then I allow them to be overridden by parameters in the event generator configuration file. When we have real data, the default values might come from the values that were set for the run we are currently simulating.