next up previous contents
Next: Plexus Up: The MINOS Off-line Software Previous: Modules, Algorithms and Candidates   Contents

Subsections


Conventions

Last significant change: 2002/12/04


Coordinate Systems and Plane Numbers

Coordinate systems used by MINOS are right-handed. When referenced to the outside world a coordinate system of x-y-z is normally used. This has a $+z$ direction that is the horizontal component of the beam direction, $+y$ that is locally vertical and $+x$ chosen to make it right-handed. For the near and far detectors it is convenient to refer to x-y-z as detector west, up, and detector north even though the axis directions aren't exactly compass west and north.

Plane numbers in each detector count steel planes and start at zero. Scintillator planes are referenced by the steel to which they are attached on the downstream side. Thus the correct pairing is active$+$passive. For the near and far detectors the first (zeroth) steel plane has no active plane upstream. The origin of the z axis is close-to but upstream of the front face of the first plane (steel or scintillator).

Each detector has a well defined u-v-z system, with the u-v origin at the center of the coil4.1 as shown in Figure 4.1. Planes orientations are referred to by the axis which the individual strips map out (and not the axis along which they lie); strip numbers start with zero and increase with increasing u or v. Only in the CalDet does u-v correspond to x-y.

Figure 4.1: Definition of coordinate systems, plane views, strip numbering, and strip ends for all three MINOS detectors.
\includegraphics[scale=0.8]{PlaneView.eps}


Enumerations

The offline code uses enumeration types to give specific user-friendly names to a related collection of values. Coding conventions require the enumerations to be put in a namespace or class and that the specific value names start with the letter 'k' (indicating a constant).


DetectorType

The enumeration for distinguishing between the three detectors is one of type DetectorType::Detector_t4.2. Variables of this type can take on the values: DetectorType::kNear, DetectorType::kFar and DetectorType::kCalDet. Code that needs to differentiate between the detectors should always use one of these symbolic values.

The specific values given are equivalent to bit masks but normal user code should not use this feature. In general user code should never make reference to the specific values that the symbolic names are assigned to; only the symbolic values should be used.


SimFlag

Often it is necessary to distinguish between data from the DAQ and simulation events, generally for purposes of database interactions where calibration, plex, geometry constants differ. The SimFlag::SimFlag_t type is used for this purpose with values: kData, kDaqFakeData, kMC, and kReroot. At this time kDaqFakeData and kMC are not used. The kReroot value indicates data that derives from the GEANT3 (fortran) based GMINOS that is post-processed via rerootjob.


Plane View and Coverage

Plane orientations form another enum list; the PlaneView::PlaneView_t values kU, kV are used by all three detectors. The CalDet also has some planes of the kB orientation with the plane horizontal and the strips running parallel to the beam direction.

Scintillator planes provide different coverages of the steel to which they are attached. Bare steel planes take on a PlaneCoverage::PlaneCoverage_t value of kUninstrumented; kNoActive is provided as a synonym. All far detector and CalDet planes with scintillator attached have values of kTotal (kComplete is a synonym), while the near detector planes can be either kNearFull or kNearPartial.

The far detector veto shield is problematic in regard to both plane view and coverage as the orientations form no regular pattern and change over time. These necessitate an extension of the PlaneView and PlaneCoverage types to have special cases to map out all the veto shield alternatives. For further information on how the veto shield is handled see Section 5.7.


StripEnd

Each scintillator strip has a ``$-$'' (kNegative) and a ``$+$'' (kPositive) end. The symbolic constants are of type StripEnd::StripEnd_t. For the near and far detectors these are conventially referred to as the east (kEast) and west (kWest) end. For the CalDet convention refer to Figure 4.1. In the near and far detectors some logical strips are composed of two physical strips. These subparts are referred to by the same StripEnd convention which also includes a kWhole value.


Electronics Readout Types

Not all raw electronics channels are attached to PMT pixels that recieve light from scintillator strips in normal planes. Electronics channels can be mapped (see Chapter 5) to an identifier of type ReadoutType::Readout_t that distinguishes between: kScintStrip, kPinDiode, kFlashTrigPMT, kVACommonMode, kTriggerOR, kCerenkov, kTOF and kTimingFid readouts. The last three should only ever occur in the CalDet data. Unexpected channels are tagged with kUnknown.

Electronics channel and pixel identifiers use the ElectType::Elec_t type found in Conventions/ElecType.h to differentiates between kVA and kQIE electronics.

Units and Physical Quantities

The Conventions/Munits.h (Minos units) header defines a namespace in which a number of conversion factors are given. Each value represents the scaling factor which converts a quantity in units of that type to the base unit of the same dimensionality (length, time, mass, etc.). In general the base units are the traditional S.I. MKS system. Users need to convert quantities into the base units only at the point they are importing or exporting the value to/from any series of calculations that are done within the system. These points of conversion include:

If these conventions are followed then there is no need to perform any conversions during calculations except where necessary to interface to non-conforming packages. Additionally, this consistency ensures that the result of any calculation will be independent of what the underlying base unit is. Geant4 uses two independent versions of G4Units.h to test their code - if the code is consistent then the choice of base units is irrelevant and one gets exactly the same output.

#include "Conventions/Munits.h"
//
// macroscopic quantities use MKS as base units
//
// Conversion of quantities from external sources to base units.
// One does this conversion when a value enters a calculation stream
// from a hardcoded values in the source code, user input, 
// or the database.
//
Double_t rise       = 10.0 * Munits::cm;
Double_t run        =  4.0 * Munits::meter;
Double_t macro_mass =  1.0 * Munits::kg;
Double_t charge     = Munits::eplus; // unit charge in Coulombs
Double_t bfield     = 15 * Munits::kilogauss;
Double_t velocity   = 3.1e7 * Munits::m/Munits::s;
// if column in database table were stored in mm
Double_t offset     = dbiData->GetAlignmentOffset() * Munits::mm;
// if user config info was requested in cm
Double_t fAnaZmin   = command->PopFloatOpt() * Munits::cm;
// if xpkg package doesn't conform to using Munits
Double_t silly      = xpkgObj.GetDistance() * Munits::inch;

//
// use of quantities
//
Double_t angle_rad = TMath::ATan2(rise,run);
Double_t force = charge * velocity * bfield;

//
// conversion to alternative units for output, including
// printing, histogramming and writing to the database.
//
cout << "the 'run' distance in km is " << run / Munits::km << endl;
cout << "the angle in degrees is " << angle_rad / Munits::degree << endl;
// fill a histogram who's axis is in mm
myhist->Fill(rise/Munits::mm);
// call something in the xpkg package expecting feet
xpkgObj.SetFeetLength(offset/Munits::feet);

The exception to the above is that particle energies, masses and momenta are expected to be handled in a HEP system with a base unit of GeV and where the speed of light, $c$, is 1.

// use of GeV as base unit for particles (implicit c=1)
Double_t pmass   = 938.27231 * Munits::MeV;
Double_t ptot    = 10.0 * Munits::GeV;
Double_t penergy = TMath::Sqrt(ptot*ptot+pmass*pmass); // implicit c=1
Double_t gamma   = energy/pmass;
Double_t beta    = ptot/energy;  // = TMath::Sqrt(1.-1./(gamma*gamma));

For those prefer to work in an all MKS system and explicitly deal with all the factors of $c$ the correct procedure is:

Double_t energy_in_joules     = penergy * Munits::hep2baseEnergy;
Double_t mass_in_kg           = pmass   * Munits::hep2baseMass;
Double_t macroscopic_momentum = ptot    * Munits::hep2baseMomentum;

Double_t pc    = macroscopic_momentum * Munits::c_light;
Double_t pc_2  = pc*pc;
Double_t mc2   = mass_in_kg*Munits::c_2
Double_t mc2_2 = mc2*mc2
Double_t cross_check = TMath::Sqrt(pc_2+mc2_2);
cout << " energy in joules " << energy_in_joules << " " << cross_check << endl;

If the the overabundance of the Munits:: qualifier seems onerous one can eliminate the need to explicitly qualify the namespace by use of:

using namespace Munits;

// now one is free to simply give the unit's name, but take care that 
// simple variable names such as "m" and "cm" will need to be qualified
// if they are obsured by local variables.  No warning will be given.

Double_t cm = 12345;
cout << " cm:  local " << cm << "   Munits:: " << Munits::cm << endl;
// results in " cm:  local 12345.000000   Munits:: 0.010000"

In addition to the unit conversions there are a few other handy numbers, mostly physical quantities, that are available. A few, necessary for unit conversion, are in the Munits:: namespace while the others are in the Mphysical:: namespace. Use of Conventions/Mphysical.h brings Conventions/Munits.h along with it.


Table 4.1: Units for macroscopic quantities available in Munits.h
length meter, m
millimeter, mm, centimeter, cm, kilomenter, km
micrometer, nanometer, angstrom, fermi
inch, foot
length$^2$ meter2, m2
millimeter2, mm2, centimeter2, cm2, kilometer2, km2
barn, millibar, microbarn, nanobarn, picobarn
length$^3$ meter3, m3
millimeter3, mm3, centimeter3, cm3, kilometer3, km3
angle radian, rad
milliradian, mrad, degree, deg
solid angle steradian, sr
time second, s
nanosecond, ns, millisecons, ms, picosecond
frequency hertz
kilohertz, megahertz
macroscopic energy joule
macroscopic mass kilogram, kg
gram, g, milligram, mg
force newton
pressure hep_pascal (to avoid keyword)
bar, atmosphere
electric charge coulomb
electric current ampere
milliampere, microampere, nanoampere
electric potential volt, kilovolt, megavolt
electric resistance ohm
electric capacitance farad
millifarad, microfarad, nanofarad, picofarad
power watt
magnetic flux weber
magnetic field tesla
gauss, kilogauss
inductance henry
temperature kelvin
amount of substance mole
activity becquerel, curie
absorbed dose gray
luminous intensity candela
luminous flux lumen
illuminance lux
scales perCent, perThousand, perMillion



Table 4.2: HEP units (implicit $c=1$) available in Munits.h
HEP particle energy ($c$=1) gigaelectronvolt, GeV
electronvolt, eV
kiloelectronvolt, keV
megaelectronvolt, MeV
teraelectronvolt, TeV
petaelectronvolt, PeV
HEP particle momenta GeV, etc.
HEP particle mass GeV, etc.
energy conversion hep2baseEnergy
momentum conversion hep2baseMomentum
mass conversion hep2baseMass



Table 4.3: physical quantities available in Munits.h
positron charge in Coulomb e_SI
positron charge in base units eplus
speed of light ($c$) non-HEP c_light
c$^2$ c_squared, c_2
c$^4$ c_4



Table 4.4: physical quantities available in Mphysical.h
$\pi$ & co. pi, twopi, halfpi, pi2
particles/mole Avogadro
speed of light ($c$), non-HEP c_light, c_squared
Plank's constant h_Plank, hbar_Planck, hbarc, hbarc_squared
electron charge (-eplus) electron_charge, e_squared
simple masses, non-HEP electron_mass_c2, proton_mass_c2, neutron_mass_c2, amu_c2, amu
free space mu0, epsilon0
electromagnetic coupling elm_coupling, fine_structure_const
classic_electr_radius, electron_Compton_length, Bohr_radius
alpha_rcl2, twopi_mc2_rcl2
Boltzmann constant k_Boltzmann
STP STP_Temperature, STP_Pressure, kGasThreshold
gravitational constant G_N



next up previous contents
Next: Plexus Up: The MINOS Off-line Software Previous: Modules, Algorithms and Candidates   Contents
MINOS Software 2017-10-29