Last significant change: 2002/12/04
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 direction that is the horizontal component of the beam direction, that is locally vertical and 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 activepassive. 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.
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).
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.
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 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.
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.
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.
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, , 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 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.