Geometry

Last significant change: 2008/01/15

NB: This chapter is appropriate for MINOS software dated more recently than 2006/09/19. The first release after this date was R1.24.1. For those using R1.24.0 or prior, please refer to the previous chapter entitled UgliGeometry.

Introduction

The UgliGeometry and GeoGeometry packages together provide services for managing the physical placement of detector elements in 3-space. The UgliGeometry package provides the following services:

• A singleton loan pool (UgliLoanPool) for managing the geometry objects. The geometry configuration is also done through the UgliLoanPool interface.
• Light-weight proxy handle classes (UgliXXXHandle) for accessing the geometry objects.
• Database interface classes (UgliDbiXXX) for accessing the geometry database tables.

The GeoGeometry package provides classes for building the geometries using ROOT's TGeoManager class and associated classes. A constructed geometry is manifested as a GeoGeometry object.

Creating a geometry

The user does not work directly with a GeoGeometry object, but instead works through a UgliGeomHandle. These UgliGeomHandles are lightweight proxy objects that do little work of any substance. During the creation of a UgliGeomHandle, a loan pool of real GeoGeometry objects is searched for an appropriate object. If no match is found, a new GeoGeometry will be created. The UgliGeomHandle then forwards member function calls to the corresponding GeoGeometry member function. This allows the UgliGeomHandle to share the larger underlying collection of information and it lowers the overhead of the creation and deletion of UgliGeomHandles.

This approach also allows the UgliGeomHandles to be created on the stack and thus avoids a common source of memory leaks. The lookup procedure is so fast that users should not be concerned with (or even attempt) to retain a handle, but rather should construct one from a VldContext whenever one is needed.

#include "UgliGeometry/UgliGeomHandle.h"

  // retrieve a copy of the VldContext object identifying 
  // the configuration of the current record
  VldContext vldc = [..]

  // create a UgliGeomHandle (on the stack)
  UgliGeomHandle ugh(vldc)

  [....]
  // work with UgliGeomHandle and it gets automagically destroyed
  // when the code block ends, but the next invocation is
  // likely to acquire the same underlying GeoGeometry without
  // significant overhead.

Definitions

This section will define some terms used in the description of the available geometry configuration options.

Material/Mixture

A material or mixture is constructed using the class TGeoMaterial or its derived class TGeoMixture, and is defined from its composition and density. The list of available materials and mixtures and their definitions can be obtained by constructing a geometry and using the handle's ls(Option $\underline{ \ }$t* opt) method with the ``m'' option to print them. For example:

loon[0] VldContext vldc(Detector::kFar,SimFlag::kData,VldTimeStamp());
loon[1] UgliGeomHandle geo(vldc);
loon[2] geo.ls("m");

The result of this command is to print all available materials in the list, whether or not the material is actually used in the build of the detector. A partial list of available materials is shown Figure 7.1.

Figure 7.1: A partial list of available materials.

Medium

A medium is constructed using the class GeoMedium (derives from TGeoMedium), and is defined from a Material and a set of tracking parameters used to determine how transport is to be carried out through the medium. The list of available media and their definitions can be obtained by constructing a geometry and using the UgliGeomHandle::ls method with the ``M'' option to print them. For example:

loon[0] VldContext vldc(Detector::kFar,SimFlag::kData,VldTimeStamp());
loon[1] UgliGeomHandle geo(vldc);
loon[2] geo.ls("M");

The result of this command is to print all available media, whether or not the medium is actually used in the build of the detector. A partial list of available media is shown Figure 7.2.

Figure 7.2: A partial list of available media.

The medium names follow the convention of <basename> $\underline{ \ }$B<ifld> where ifld is defined as one of the enumerated swim method types in the GeoGeometry/Geo namespace:

  enum ESwimMethod {
    // Bfield swim method.  Assigned to medium and used to determine
    // transport model used to swim particles through that medium in VMC.
    kNoFieldSwim,  // swim as though no b-field
    // Runge-Kutta method recommended for fields with a strong gradient.
    kRungeKutta,
    // Step-wise helix method recommended for fields with a small gradient.
    // Tracking is performed along helix for each step, assuming a
    // constant B-field with the value of the step mid-point.
    // Better performance than kRungeKutta.
    kStepHelix,
    kUnknownSwimMethod
  };

so that, for example, a medium with the extension $\underline{ \ }$B1 is designated to use a transport method which makes use of the Runge Kutta method to swim through a magnetic field with a strong gradient.

The tracking parameters are the standard Geant3 tracking parameters. These are also defined as an enumerated type in the Util/UtilMCFlag namespace as:

  enum ETracking {
    // Tracking parameters used in definition of medium.  Could put this in
    // Geo namespace, but it seems to group better with ECut and EProcess.
    kISVOL,   // sensitivity flag, <= 0 (not sensitive), > 0 (sensitive)
    kIFIELD,  // magnetic field swim method (see Geo::ESwimMethod)
    kFIELDM,  // maximum field (kGauss)
    kTMAXFD,  // maximum angle due to field permitted in one step (deg)
    kSTEMAX,  // maximum step permitted (cm)
    kDEEMAX,  // maximum fractional energy loss in one step (0 < DEEMAX <= 1)
    kEPSIL,   // boundary crossing precision (cm)
    kSTMIN,   // min step due to energy loss or multiple scat or b-field (cm)
    kUnknownTracking
  };

and are configurable as will be shown below.

Detector Components

A MINOS Geometry concept is the Detector Component, expressed as an enumerated type in the Geo namespace:

  enum EDetComponent {
    // Detector components
    kMars,         // rock
    kLinr,         // cavern liner
    kHall,         // cavern hall
    kStpScint,     // strip scintillator
    kStpTiO2,      // strip TiO2 coex coating
    kMdlAlSkin,    // scint module Al skin
    kMdlAir,       // scint module Air fill
    kPlnScint,     // scint plane Air fill
    kPlnSteel,     // steel plane
    kPlnAirGap,    // scint/steel pln air gap
    kCRGapWater,   // coil region air gap water
    kCRGapCoil,    // coil region air gap coil
    kCRGapThroat,  // coil region air gap throat
    kCRGapFlange,  // coil region air gap flange
    kCRGapBypass,  // coil region air gap bypass
    kCRStlWater,   // coil region steel pln water
    kCRStlCoil,    // coil region steel pln coil
    kCRStlThroat,  // coil region steel pln throat
    kCRStlNeck,    // coil region steel pln neck
    kCRStlHole,    // coil region steel pln hole
    kCRStlDetail,  // coil region steel pln detail
    kCRSctWater,   // coil region scint pln water
    kCRSctCoil,    // coil region scint pln coil
    kCRSctThroat,  // coil region scint pln throat
    kCRSctFlange,  // coil region scint pln flange
    kCRSctBypass,  // coil region scint pln bypass
    kRCCoil,       // return coil
    kRCAir,        // return coil air fill
    kRCShaft,      // return coil shaft
    kVSStpScint,   // strip scintillator
    kVSStpTiO2,    // strip TiO2 coex coating
    kVSMdlAlSkin,  // scint module Al skin
    kVSMdlAir,     // scint module Air fill
    kVSPlnScint,   // scint plane Air fill
    kUnknownDetComponent       // unknown
  };

Many volumes in the detector geometry may have the same EDetComponent type, but all volumes of the same EDetComponent type share common attributes such as assigned base medium and swim method. For example, there are many scint module aluminum ``skin'' shapes and sizes in the detector, but they all are of the same EDetComponent type kMdlAlSkin.

The use of the detector component concept makes the configuration of base medium and swim method more straightforward. Associations are maintained between the detector component and its medium, field strength, and swim method.

The list of available detector component and their definitions can be obtained by constructing a geometry and using the UgliGeomHandle::ls method with the ``d'' option to print them. For example:

loon[0] VldContext vldc(Detector::kFar,SimFlag::kData,VldTimeStamp());
loon[1] UgliGeomHandle geo(vldc);
loon[2] geo.ls("d");

The result of this command is to print the list of the detector components in the constructed geometry and their associated parameters as shown in the example below.

Figure 7.3: A list of detector components and their associated medium, field strength and swim method in a far detector geometry.

From left to right, the columns contain the detector component of type Geo::EDetComponent, the assigned medium by name, the assigned field strength of type Geo::EFldStrength, and the assigned swim method of type Geo::ESwimMethod. Of these, the one not previously discussed is the field strength. The field strength is an enumerated type:

  enum EFldStrength {
    // Field strength assigned to detector components
    kNoField,      // e.g. hall,rock
    kLowField,     // e.g. scint plane,plane air gaps
    kHighField,    // e.g. steel plane, coil
    kUnknownFldStrength // unknown
  };

and is a device for further categorizing the detector components. It is used for configuration purposes to configure the swim method for all detector components corresponding to a given field strength.

Configuration

A geometry is configured through the UgliLoanPool singleton interface. Supported configuration options are described in this section. The current state of the geometry configuration can be obtained using the UgliLoanPool instance Print() method:

loon[0] UgliLoanPool::Instance()->Print();

Configuration of medium assigned to detector component

The medium assigned to a given detector component is configurable by name using the interface:

   UgliLoanPool::Instance()->SetMedium(Geo::EDetComponent comp, 
                                       const char* medium);

For example, to configure the rock and hall liner medium for the far detector geometry to the ``old'' rock values:

loon[0] UgliLoanPool::Instance()->SetMedium(Geo::kMars,"ROCK");
loon[1] UgliLoanPool::Instance()->SetMedium(Geo::kLinr,"CONCRETE");
loon[2] VldContext vldc(Detector::kFar,SimFlag::kData,VldTimeStamp());
loon[3] UgliGeomHandle geo(vldc);
GeoGeometry build for validity {   Far|  Data|2008-01-15 20:45:28.232089000Z}.
Medium for component Mars set to ROCK overriding default GREENSTONE.
Medium for component Linr set to CONCRETE overriding default GREENSTONE.
Successfully opened connection to: mysql:odbc://minos-db.spa.umn.edu/offline
This client, and MySQL server (MySQL 5.0.27-log) does support prepared statements.
...

To determine the list of available media, use the UgliGeomHandle::ls(``M'') option described above.

Configuration of swim method assigned to detector component

The swim method assigned to a given detector component is configurable by component field strength using the interfaces:

   UgliLoanPool::Instance()->SetSwimMethodLowField(Geo::ESwimMethod method);

for low field strength components, and:

   UgliLoanPool::Instance()->SetSwimMethodHighField(Geo::ESwimMethod method);

for those components designated as having a high field strength. Typical high field strength components are the coil region and steel planes. Typical low field strength components are the scint plane and air gap regions between plane pairs.

For example, to configure the swim method for the low field detector components to use the step-wise helix approach:

loon[0] UgliLoanPool::Instance()->SetSwimMethodLowField(Geo::kStepHelix);
loon[1] VldContext vldc(Detector::kFar,SimFlag::kData,VldTimeStamp());
loon[2] UgliGeomHandle geo(vldc);
GeoGeometry build for validity {   Far|  Data|2008-01-15 21:34:01.440105000Z}.
SwimMethod for components w/field strength LowField set to StepHelix overriding default NoFieldSwim.
Successfully opened connection to: mysql:odbc://minos-db.spa.umn.edu/offline
This client, and MySQL server (MySQL 5.0.27-log) does support prepared statements.
...

The default for the low field strength media is to use a transport method kNoFieldSwim which transports the particle through the medium as though there is no magnetic field present.

Configuration of tracking flags assigned to a medium

There are three sets of parameters that may have values assigned on a medium specific basis. The setting of the parameters will determine how particle transport is handled through volumes of this medium type.

The setting of the three types of parameters are all contained within the Util/UtilMCFlag namespace as enumerated types ECut, EProcess, and ETracking. These parameters are similar to those used in Geant3, and hold the same meaning as in that simulation.

The first two enumerated types ECut and EProcess:

  enum ECut {
    // Flags to specify threshold cuts.  Kinetic energy cuts in GeV.
    // Time of flight cut in seconds.  Specified in order that they
    // appear in Geant3 "CUTS" list.
    kCUTGAM, // cut for gammas
    kCUTELE, // cut for electrons
    kCUTNEU, // cut for neutral hadrons
    kCUTHAD, // cut for charged hadrons
    kCUTMUO, // cut for muons
    kBCUTE,  // cut for electron bremsstrahlung
    kBCUTM,  // cut for muon and hadron bremsstrahlung
    kDCUTE,  // cut for delta rays by electrons
    kDCUTM,  // cut for delta rays by muons
    kPPCUTM, // total energy cut for direct pair production by muons
    kTOFMAX, // time of flight cut in seconds
    kUnknownCut
  };

  enum EProcess {
    // Flags to control physics processes.  In general:
    //   0 = process is disabled.
    //   1 = process enabled with production of secondaries
    //   2 = process enabled without production of secondaries
    // unless otherwise specified.
    // Process flags are listed in alphabetical order.
    kANNI,    // Positron annihilation
    kBREM,    // Bremsstrahlung
    kCOMP,    // Compton scattering
    kDCAY,    // Decay in flight
    kDRAY,    // Delta ray production
    kHADR,    // Hadronic interactions.
              // HADR 0=None
              //  1,2,3=GHEISHA
              //      4=FLUKA
              //      5=MICAP(low E)/FLUKA(high E)
              //      6=GCALOR
    kLOSS,    // Continuous energy loss
              // LOSS 0=None
              //      1=Continuous loss w/drays above DCUTE, fluctuations below
              //      2=Continuous loss w/o drays and full Landau fluctuations
              //      3=Same as 1
              //      4=Energy loss without fluctuation.
    kMULS,    // Multiple scattering
              // MULS 0=None
              //      1=Multiple scattering according to Moliere theory
              //      2=Same as 1
              //      3=Pure Gaussian scattering according to the Rossi formula
    kMUNU,    // Muon nuclear interaction
    kPAIR,    // Pair production
    kPFIS,    // Photofission (nuclear fission induced by photon)
    kPHOT,    // Photoelectric effect
    kUnknownProcess
  };

are globally set in the Virtual Monte Carlo (VMC) configuration script, via the TVirtualMC class interface. (For an example, see the ParticleTransportSim/macro/PTSim $\underline{ \ }$g3Config.C script.)

To override the globally set and/or default settings for these flags on a medium specific basis, use the methods:

   UgliLoanPool::Instance()->SetProcess(UtilMCFlag::EProcess flag,
                                        Int_t value, const char* medium);
   UgliLoanPool::Instance()->SetLoss(UtilMCFlag::ECut flag,
                                     Double_t value, const char* medium);

For example, to turn off explicit delta ray production and activate continuous energy loss with Landau fluctuation in near detector bedrock only:

   UgliLoanPool::Instance()->SetProcess(UtilMCFlag::kDRAY,0,"NEARBEDROCK");
   UgliLoanPool::Instance()->SetLoss(UtilMCFlag::kLOSS,2,"NEARBEDROCK");

The third set of tracking parameters, described by ETracking, are set at the time of construction of the mediums on a medium specific basis. These are:

  enum ETracking {
    // Tracking parameters used in definition of medium.  
    kISVOL,   // sensitivity flag, <= 0 (not sensitive), > 0 (sensitive)
    kIFIELD,  // magnetic field swim method (see Geo::ESwimMethod)
    kFIELDM,  // maximum field (kGauss)
    kTMAXFD,  // maximum angle due to field permitted in one step (deg)
    kSTEMAX,  // maximum step permitted (cm)
    kDEEMAX,  // maximum fractional energy loss in one step (0 < DEEMAX <= 1)
    kEPSIL,   // boundary crossing precision (cm)
    kSTMIN,   // min step due to energy loss or multiple scat or b-field (cm)
    kUnknownTracking
  };

To see the default settings on a medium-by-medium basis, use the UgliGeomHandle::ls(``M'') method as described above.

To change the default configuration for a given medium, use the method:

   UgliLoanPool::Instance()->SetProcess(UtilMCFlag::ETracking flag,
                                        Double_t value, const char* medium);

For example, to change the boundary crossing precision for the far detector rock to 0.01 cm:

   UgliLoanPool::Instance()->SetTracking(UtilMCFlag::kEPSIL,0.01,"GREENSTONE");

Note that for any of the configuration methods involving specifying a configuration option by medium name, it is possible to narrow the degree of specificity of the medium name to include the swim method. For example to configure the tracking flag value in the above example only for the GREENSTONE medium with no field swimming activated:

   UgliLoanPool::Instance()->SetTracking(UtilMCFlag::kEPSIL,0.005,
                                         "GREENSTONE_B0");