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.
Here is a list of things that already exist. You should use these instead
of inventing your own.
- #include <cmath>
This defines the value of pi using std::M_PI.
- #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
- There are many enum's defined in the Mu2e code. These include:
When you need to define your own a constant, or other
there are several places that it might make sense to define
it. These include:
Here are a few comments about each of these choices:
- enums or static const variables in header files.
- the conditions data system.
- the geometry system (maybe someday this will be
a subset of conditions data?)
- run time parameters
- constants written directly into files.
- 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.
- 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.
- 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).
- Run time parameters
These are parameters specified in the module defintion in the .fcl file.
- 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.)
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.
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.
- The nominal (design value) of the start time of the live window, 700 ns.
- The orbital period of the debuncher, 1694 ns.
- The nominal end of the live window, which might or might not be
the same as the orbital period of the debuncher.
- The actual value of the start time for the actual DAQ on a
- The actual value of the end of DAQ window for a particular run.
- The start and end of the live window to be used by the event
generators in a particular run of the MC.
- The start and end of the live window to be used by the digitizer code
in a particular run of the MC.
This file last modified Tuesday, 16-Aug-2011 18:33:52 CDT