next up previous contents
Next: About this document ... Up: The MINOS Off-line Software Previous: Minos Event Display (sub)   Contents


Monte Carlo Information

Begun: 2004/10/04, M. Kordosky
Last significant change (new ion codes): 2007/07/16, R. Hatcher
Modified to add ParticleTransportSim section: 2007/04/22, S. Kasahara

This section documents some of the Monte Carlo truth information which may be accessed by offline jobs. The emphasis is on the StdHep block. The information was gathered from emails, GEANT documentation, private conversations and ``legacy'' web-pages (most of which were authored by Robert Hatcher).

Accessing Truth Information

It is possible to configure GMINOS to record a list of interesting processes in each event. The information eventually shows up as a TClonesArray of TParticle objects stored inside SimSnarlRecords. Inside the offline code (e.g., in a JobModule) users may retrieve the information via:

SimSnarlRecord* simrec = dynamic_cast<SimSnarlRecord*>

const TClonesArray* simstdheparray = dynamic_cast<const TClonesArray*>
                                       (simrec -> FindComponent("TClonesArray",

// loop over array of TParticles
Int_t nstdhep = simstdheparray->GetLast()+1;
for ( Int_t istd = 0; istd < nstdhep; istd++ ) {
  TParticle* simstdhep = 
  // Do whatever you want
  // See NtpMCModule::FillNtpMCStdHep() for examples
In addition the truth information is recorded by the JobControl module NtpMCModule as NtpMCStdHep objects which are stored in NtpMCRecords. That's a mouthful! Exploring the information in NtpMCRecords is pretty easy inside a loon session:
// open a file
loon [0] TFile f("f24110001_0000.sntp.R1.9.root");

// what's in the file?
loon [1] .ls
TFile**         f24110001_0000.sntp.R1.9.root   Persistency file
 TFile*         f24110001_0000.sntp.R1.9.root   Persistency file
  KEY: TTree    NtpMC;1 Persistency stream tree
  KEY: TTree    NtpSR;1 Persistency stream tree
  KEY: TTree    NtpTH;1 Persistency stream tree
  KEY: TNamed   FileEnd;1       PerFile End Key

// what do NtpMC records look like?
loon [2] NtpMC->Show(0);
======> EVENT:0
 NtpMCRecord     = NULL
 fUniqueID       = 0
 fBits           = 50331648
 fName           =
 fTitle          =
 fHeader.fUniqueID = 0
 fHeader.fBits   = 50331648
 fHeader.fVldContext.fUniqueID = 0
 fHeader.fVldContext.fBits = 50331648
 fHeader.fVldContext.fDetector = 2
 fHeader.fVldContext.fSimFlag = 4
 fHeader.fVldContext.fTimeStamp.fSec = 1079981341
 fHeader.fVldContext.fTimeStamp.fNanoSec = 51
 fHeader.fRun    = 24110001
 fHeader.fSubRun = 1
 fHeader.fRunType = 0
 fHeader.fErrorCode = 0
 fHeader.fSnarl  = 0
 fHeader.fTrigSrc = 0
 fHeader.fTimeFrame = -1
 fHeader.fEvent  = -1
 mc              = 1
 mc.fUniqueID    = 0
 mc.fBits        = 50331648
 mc.index        = 0
 mc.inu          = 12
 mc.inunoosc     = 14
 mc.itg          = 2212
 mc.iboson       = -99999
 mc.iresonance   = 1003
 mc.iaction      = 0
 mc.a            = 56.000000
 mc.z            = 26.000000
 mc.sigma        = 216.959991
 mc.x            = 0.056173
 mc.y            = 0.337257
 mc.q2           = -0.134168
 mc.w2           = 3.070345
 mc.emfrac       = 0.000000
 mc.vtxx         = 169.134476
 mc.vtxy         = -101.748550
 mc.vtxz         = 959.161987
 mc.p4neu[4]     = 0.000005 , 0.220568 , 3.796557 , 3.802959
 mc.p4neunoosc[4] = 0.000005 , 0.220566 , 3.796557 , 3.802959
 mc.p4tgt[4]     = 0.201376 , -0.069906 , 0.001095 , 0.928162
 mc.p4shw[4]     = 0.266551 , 0.203926 , 1.338785 , 1.321045
 mc.p4mu1[4]     = 0.000000 , 0.000000 , 0.000000 , 0.000000
 mc.p4mu2[4]     = 0.000000 , 0.000000 , 0.000000 , 0.000000
 mc.p4el1[4]     = 0.000000 , 0.000000 , 0.000000 , 0.000000
 mc.p4el2[4]     = 0.000000 , 0.000000 , 0.000000 , 0.000000
 mc.p4tau[4]     = 0.000000 , 0.000000 , 0.000000 , 0.000000
 stdhep          = 9
 stdhep.fUniqueID = 0, 0, 0, 0, 0, 0, 0, 0, 0
 stdhep.fBits    = 50331648, 50331648, 50331648, 50331648, 
                   50331648, 50331648, 50331648, 50331648, 
 stdhep.index    = 0, 1, 2, 3, 4, 5, 6, 7, 8
 stdhep.parent[2] = -1 , -1
, -1 , -1
, 1 , 1
, 1 , 1
, 0 , 0
, 2 , 2
, 5 , 5
, 5 , 5
, 5 , 5
 stdhep.child[2] = 4 , 4
, 2 , 3
, 5 , 5
, -1 , -1
, -1 , -1
, 6 , 8
, -1 , -1
, -1 , -1
, -1 , -1
 stdhep.IstHEP   = 0, 0, 11, 1, 1, 3, 1, 1, 1
 stdhep.IdHEP    = 12, 1056026000, 2212, 1055025000, 12, 
                   10000222, -211, 211, 2212
 stdhep.mass     = 0.000000, 52.103485, 0.903351, 51.174881, 
                   0.000000, 1.752240, 0.139568, 0.139568, 
 stdhep.p4[4]    = 0.000005 , 0.220568 , 3.796557 , 3.802959
, 0.000000 , 0.000000 , 0.000000 , 52.103485
, 0.201376 , -0.069906 , 0.001095 , 0.928162
, -0.201376 , 0.069906 , -0.001095 , 51.175323
, -0.266546 , 0.016642 , 2.457773 , 2.472240
, 0.467927 , 0.134020 , 1.339880 , 2.258881
, 0.093360 , 0.191389 , 0.293592 , 0.388615
, 0.254709 , 0.230348 , 0.752490 , 0.838843
, 0.119858 , -0.287717 , 0.293798 , 1.031423
 stdhep.vtx[4]   = 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000
, 1.691345 , -1.017485 , 9.591620 , 0.000000

The NtpMC tree contains NtpMCRecord objects. The objects have three main components:

Event ``time'' as well as run, snarl and event numbers.
An array of NtpMCTruth objects. For Far detector events the array should only hold one object. The NtpMCTruth objects record information on the final state of the neutrino interaction. This includes the neutrino flavor and momentum 4-vector, true vertex, interaction type (CC,NC), interaction mode (QE, resonance production, DIS, coherent pion production) and event kinematics (e.g. x, y, q-squared, W-squared).
An array of NtpMCStdHep objects. Each object corresponds to one particle and has words for the particle type (IdHEP), mass (mass), momentum 4-vector ( p4[4]) and production vertex (vtx[4]). Additionally a status code (IstHEP) is provided to indicate the mechanism by which the particle was produced. Finally, two pairs of words (parent[2], child[2]) provide a range of indices indicating the immediate parent(s) and daughters of the particle. Array indexing begins at zero. An index of -1 indicates those particles that initiated the event. In neutrino events these are the neutrino and the target nucleus.

Various Numerical Codes

Two codes are used to denote the sort of interaction that occurred between the neutrino and the target. These codes, known as ``Iaction'' and ``Iresonance'', are shown in Tables 21.1-21.2. The tables are valid for NEUGEN3 but perhaps not for earlier versions.

Table 21.1:
Iaction Codes
code interaction type
0 neutral current
1 charged current

Table 21.2:
Iresonance Codes
code interaction mode
1001 Quasi-elastic
1002 Resonance production
1003 Deep inelastic scattering
1004 Coherent pion production
1005 Inverse Muon Decay

Table 21.3:
Common IdHEP Codes
Code Particle
22 photon
11, 13, 15 electron, muon, tau
12, 14, 16 neutrinos: electron, muon, tau
211, 111, 221 charged pion, neutral pion, eta
213, 113, 223 charged rho, neutral rho, omega
321, 311, 310, 130 charged kaon, neutral kaon, k-short, k-long
2212, 2112 proton, neutron
1114, 2114, 2214, 2224 Delta(1232): -, 0, +, ++
28 ``geantino'' (placeholder)
100200-100255 neugen2 resonance
10000200-10000255 neugen3 resonance

Table 21.3 lists those particles most commonly seen in our events. The numbering convention and the full table are documented in the PDG. In particular many resonances have been left out of the table. Anti-particles have a negative sign in front of the numeric code (e.g. a negative pion is -211). Geantinos are used by NEUGEN for bookkeeping.

Atomic nuclei or ions are marked with a 10 digit code, such as 1056026000. There are now two canonical encoding schemes. The older StdHep scheme uses 1AAAZZZJJJ where AAA is the atomic mass, ZZZ is the charge and JJJ is the (angular) spin. Currently the spin portion is unused. Therefore 1056026000 denotes Fe-56. The newer scheme was introduced in the 2006 PDG section on Monte Carlo Numbering (and hereforth referred to as PDG2006). This scheme uses 10LZZZAAAI where AAA and ZZZ are as above, L is the number of charmed Lambdas, and I distinguishes various excited states. Since MINOS is working with non-exotic matter both L and I will generally be zero. In the PDG2006 scheme Fe-56 would be 1000260560.

To facilitate working with these codes there are some useful functions defined in Util/UtilPDG.h; these are within the UtilPDG namespace (and thus need to be qualified).

The IstHEP status codes coming out of the NEUGEN3 generator deviate from the STDHEP conventions and are shown in Table 21.4. Particles of status code 1 are those that are fed into GEANT for propogation through the detector; these and their secondaries give rise to hits that record energy depositions in the active detector elements. The special status code 999 indicates a bogus entry used by GMINOS to transmit information about the flux; do not use these in any kinematics calculations.

In addition, if GMINOS deems the results of a process step to be ``interesting'' it will record the daughter products with a status code in the ranges of 201-230, 301-309, 1201-1230 where the code indicates the process that generated the secondaries as shown in Table 21.5. In general this GEANT3 tagging means a secondary exceeded a kinematic energy threshold set for that process (see Section 21.3). If the secondaries arise from a decay then the state of the decaying particle is also recorded. For decays (other than taus and heavy hadrons) the resulting daughters will be recorded as status code 205; in addition the parent that decayed will have an entry made with status code 1205 representing the state of the parent at the time of the decay (starting with daikon release).

Table 21.4:
NEUGEN status codes
Code Description
0 primaries (neutrino and nucleus)
1 stable (not a resonance) final state particle
3 decay (usually of a resonance)
11 marks the target nucleon
14 particles that underwent intra-nuclear scattering

Table 21.5:
IstHEP Status Codes
Name Code Description
NEXT 201 particle has reached the boundary of current volume
MULS 202 multiple scattering
LOSS 203 continuous energy loss
FIEL 204 bending in magnetic field
DCAY 205 particle decay
PAIR 206 photon pair-production or muon direct pair production
COMP 207 Compton scattering
PHOT 208 photoelectric effect
BREM 209 bremsstrahlung
DRAY 210 delta ray production
ANNI 211 positron annihilation
HADR 212 hadronic interaction
ECOH 213 hadronic elastic coherent scattering
EVAP 214 nuclear evaporation
FISS 215 nuclear fission
ABSO 216 nuclear absorption
ANNH 217 anti-proton annihilation
CAPT 218 neutron capture
EINC 219 hadronic elastic incoherent scattering
INHE 220 hadronic inelastic scattering
MUNU 221 muon-nuclear interaction
TOFM 222 exceeded time of flight cut
PFIS 223 nuclear photo-fission
SCUT 224 the particle due to bending in magnetic field was unexpectedly crossing volume boundaries and the step has been halved to avoid this
RAYL 225 Rayleigh effect
PARA 226 parameterization activated
PRED 227 error matrix computed ( GEANT tracking)
LOOP 228 not used
NULL 229 no mechanism is active, usually at the entrance of a new volume
STOP 230 particle has fallen below energy threshold and tracking stops
LABS 301 Cerenkov photon absorption
LREF 302 Cerenkov photon reflection/refraction
SMAX 303 step limited by STEMAX
SCOR 304 correction against loss of precision in boundary crossing
CKOV 305 Cerenkov photon generation
REFL 306 Cerenkov photon reflection
REFR 307 Cerenkov photon refraction
SYNC 308 synchrotron radiation generation
STRA 309 PAI or ASHO model used for energy loss fluctuations

Examples of StdHep structures

Figures 21.1-21.4 exemplify various features that are recorded in the StdHep structure. These were generated using a JobPath that included RerootToTruth::Ana. The first column is the index into the array of TParticles, the second (in parentheses) is the status code. The ``parents'' indices delimit a range of indices that are the source of the particle. In the offline, using C++, indices start at 0 and thus -1 is used to indicate no linkage. The range of children (if any) are shown in square brackets. If one is looking for the the ``final state'' particles that come from the generator one should look for status code 1 and not follow daughter links. For each entry the right hand side of the first line shows the 4-momentum, and the second shows the position and time.

Figure 21.1 shows at $\nu _\tau $ CC event. The $\tau$ is a prompt decay, so in MINOS there is no realistic possibility of seeing the tau as an actual track. This is handled in GMINOS by allowing the tau to propogate (starting position is entry 4, status code 2 in this dump), recording the location of the decay (entry 6, status code 2) and then putting the daughter particles in as status code 1 (entries 7-9). In this event several particles underwent internuclear scattering (status code 14).

Figure 21.2 shows an ``opposite-sign di-muon'' event where the charged current event contains a charmed particle that decays into a muon (always of opposite charge as the primary). Like the $\nu _\tau $ CC event the decay of interest is prompt leading to two entries for the charmed particle (D0 meson in this case, entries 6 and 18, with status code 2) and the decay products entered with status code 1.

Figure 21.3 shows the decay in flight of a single muon. The status code 205 indicates that this is em extra information beyond the primary event as desribed in Section 21.2; 205 in particular means a decay as documented in Table 21.5. Using these entries in kinematic calculations would be double or triple counting The first entry in each dump was the particle passed to GMINOS, while the second records the state of the muon at the point of the decay. For muons that decay in flight there is no threshold for the kinetic energy of the daughters; in the first case, the muon has essentially come to rest due to energy loss before the decay.

The final event, Figure 21.4, again demonstrates the GEANT status codes. In this case one of the $K^+$'s decayed while being propogated throught the detector with sufficient kinematic energy of a decay product to warrent recording.

Figure 21.1: A charged-current $\nu _\tau $ event.
\begin{verbatim}ihep stat type <parents > px py p...
0 [ -1 -1] 1.56418 -5.88815 -14.022 0.0000e+00\end{verbatim}

Figure 21.2: A ``opposite sign di-muon'' event (CC event with charmed hadron in the final state that decays to a second muon).
\begin{verbatim}ihep stat type <parents > px py p...
130 [ -1 -1] 0.240279 1.4682 24.4065 2.4344e-12\end{verbatim}

Figure 21.3: A single muons that decay at rest or in flight.
\begin{verbatim}ihep stat type <parents > px py p...
14 [ -1 -1] 1.00203 0.998222 1.08182 3.5489e-10\end{verbatim}

Figure 21.4: A charge current event with a non-prompt decay of a primary particle.
\begin{verbatim}ihep stat type <parents > px py p...
... 111 [ -1 -1] -3.87914 -1.32384 21.6241 1.3886e-11\end{verbatim}

StdHep controls in GMINOS

GMINOS has a handy feature which allows the user to ``throttle'' the output to StdHep. At a minimum each neutrino induced event includes the final state from NEUGEN. If a resonance was produced it is usually (always?) decayed and the daughters are also shown in StdHep. Two FFREAD cards, SAVT and C2ND, are used to control the StdHep output. The SAVT card denotes the event numbers for which the StdHep information is to be saved. Therefore:

SAVT 1 7 28

would output the StdHep block for events one, seven and twenty-eight. One can save a range of events by using negative numbers:

SAVT -1 -28

That line would output the StdHep block for events one through twenty-eight. To write out every event you might do:

SAVT -1 -9999999

The C2ND card is used to set a momentum threshold (in GeV/c) for each GEANT process (listed in descending order from 1 to 39 in Table 21.5). Positive thresholds values will save all secondaries produced via the specified process provided that at least one secondary is above the threshold. Negative thresholds will save only those secondaries with a momentum larger than the (absolute value of) the threshold value. For example:

C2ND 12=0.01
C2ND 13=-0.05
would save all secondaries from 'HADR' (code 12) processes in which one secondary had a momentum larger than 10MeV/c but for 'ECOH' (code 13) processes would only save secondaries with a momentum larger than 50MeV/c. A range of values can be given as:
C2ND 60*0.02
C2ND 12=-0.1
which initially sets all sixty thresholds to 20MeV/c and then resets the 'HADR' threshold to 100MeV/c.

Currently the C2ND card only saves secondaries but in the future it may be helpful to save the primaries as well.

Regarding TrackId

GEANT operates by propagating individual particles through the detector geometry - in other words it makes ``tracks''. Interactions may create new tracks. GEANT keeps track of the tracks (clever eh?) by assigning a unique number, called TrackId, to each track. The tracks do not have to appear in the StdHep output in order to be tagged with a TrackId. DigiScintHits record the ID of the track that created them and so propagate the information into the offline framework where it is used by, among other things, the Truthifier code. At one point in the past the author noticed negative TrackIds which made him fear that there was a bug. As it turns out, it's a feature, as Robert explains:

TrackId represents an index into the StdHep table - but that table would grow to outrageous size if every particle were recorded. So instead we use the convention that -TrackId means a hit from a particle that the true TrackId begat (at some level above). Thus deep in an EM shower initiated by a high energy electron (TrackId=5 for instance) some lowly electron is going to have TrackId=-5 but the state of all the e+/e-'s in the shower are not recorded.

More recently someone noticed that hits created about seven micro-seconds after the start of the event were being attributed, via TrackId, to a pion produced at the (neutrino) vertex. In light of Robert's comment above, it's likely that the hits were produced by the neutron progeny of the original pion.


Last significant change: 2007/04/22, S. Kasahara

ParticleTransportSim (PTSim) is the name for the package that handles the particle transport through the detector geometry. PTSim begins with the event initial state and results in the energy deposition hits and storage of selected secondaries generated during the simulation through the detector. It is the replacement for GMINOS particle transport beginning with the Eggplant Monte Carlo production.

The purpose of this section is to document conventions specific to PTSim.

Status Codes

The IstHEP status code assigned to secondaries by PTSim follows the convention of using UtilIstHEP::kProdMethodOffset (400) + the UtilIstHEP::EProdMethod code assigned at particle production. A listing of such process codes is shown in Table 21.5.1.

Table 21.6: PTSim IstHEP Status Codes.
PTSim IstHEP Status Codes (UtilIstHEP::EProdMethod + 400)
Code UtilIstHEP::EProdMethod enumeration Description
400 kMPrimary Primary interaction
401 kMMultipleScattering Multiple scattering
402 kMEnergyLoss Continuous energy loss
403 kMMagneticFieldL Bending in magnetic field
404 kMDecay Particle decay
405 kMPair Photon pair production or Muon direct pair production
406 kMCompton Compton scattering
407 kMPhotoelectric Photoelectric effect
408 kMBrem Bremsstrahlung
409 kMDeltaRay Delta ray production
410 kMAnnihilation Positron annihilation
411 kMHadronic Hadronic interaction
412 kMEvaporation Nuclear evaporation
413 kMNuclearFission Nuclear fission
414 kMNuclearAbsorption Nuclear absorption
415 kMPbarAnnihilation Antiproton annihilation
416 kMNCapture Neutron capture
417 kMHElastic Hadronic elastic incoherent scattering
418 kMHInhelastic Hadronic inelastic scattering
419 kMMuonNuclear Muon nuclear interaction
420 kMTOFlimit Time of flight limit
421 kMPhotoFission Nuclear photofission
422 kMRayleigh Rayleigh scattering
423 kMNull No active process, e.g. at the entrance to a new volume
424 kMStop Particle has fallen below energy threshold
425 kMLightAbsorption Light absorption
426 kMLightScattering Light scattering
427 kMStepMax Maximum allowed step
428 kMCerenkov Cerenkov production
429 kMFeedBackPhoton Cerenkov feed back photon
430 kMLightReflection Cerenkov photon reflection
431 kMLightRefraction Cerenkov photon refraction
432 kMSynchrotron Synchrotron radiation
433 kMTransportation Transportation
434 kMNoProcess Unknown process
435 kMAnnihilationRest Positron annihilation at rest
436 kMAnnihilationFlight Positron annihilation in flight
437 kMNbarAnnihilation Antineutron annihilation
438 kMHIElastic Hadronic elastic incoherent scattering
439 kMHCElastic Hadronic elastic coherent scattering
440 kMPhotonInhelastic Photon inelastic scattering
441 kMElectronNuclear Electron nuclear interaction
442 kMPositronNuclear Positron nuclear interaction
443 kMScintillation Scintillation

In addition, a special IstHEP status code of 1000 + UtilIstHEP::kProdMethodOffset + UtilIstHEP::kMDecay is reserved for the parent of a decay process, where the state of the parent has been recorded at the position of the decay. This is shown in Table 21.5.1.

Table 21.7: PTSim IstHEP Status Codes (Specialized)
PTSim IstHEP Status Codes (Specialized)
Code Description
1404 Decay parent

StdHep controls in PTSim

The PTSimModule is configurable to allow the user to select the type of secondary to store to the output stdhep array. These configuration options, as well as the default behavior, are summarized in this section.

As with GMINOS, event interaction primaries, those with IstHEP status code $\leq 400$, are always stored to the output stdhep array.

Configuration option StdHepSave

The configuration parameter StdHepSave can be used to denote the snarl numbers for which selected secondary particles will be stored to the output StdHep array. The snarl numbers can be specified by range or as an itemized list. For example:

jc.Path("Reco").Mod("PTSimModule").Cmd("StdHepSave 1 4 10");
will store secondaries for snarls 1, 4, and 10.

Using a negative index will store the secondaries for a range of snarls. For example:

jc.Path("Reco").Mod("PTSimModule").Cmd("StdHepSave -1 -10");
stores secondaries for snarls 1 to 10, and:
jc.Path("Reco").Mod("PTSimModule").Cmd("StdHepSave 0 -5");
stores secondaries for snarls 0 to 5.

To store secondaries for every snarl, use:

jc.Path("Reco").Mod("PTSimModule").Cmd("StdHepSave 0 -9999999");
The default is to store secondaries for no snarls.

Configuration option StdHepSelectMask

The StdHepSelectMask can be used to specify the mode by which the secondaries will be selected for storage. The modes are set as bits in the mask, and an enumerated list of bits to choose from are specified in PTSim.h as enumerated type EStdHepSelectMode. Currently there are two such bits PTSim::kMomentum and PTSim::kHit, defined as follows:
All secondaries with momentum above threshold are selected for storage. The momentum threshold is set as described below.
All secondaries resulting in an energy deposition hit above hit threshold are selected for storage. The hit threshold is set as described below.
The user may specify either or both of the two selection modes, and an OR will be taken of the individual mode results to determine the final selection.

Note that if a secondary is selected for storage by one of the above means, the secondary's direct line of ancestors will be saved as well.

For example, to set both selection modes:

std::ostringstream oss;
Int_t selectmask = PTSim::kHit | PTSim::kMomentum;
oss << "StdHepSelectMask " << selectmask;

or to set selection by momentum threshold only one would specify:

std::ostringstream oss;
Int_t selectmask = PTSim::kMomentum;
oss << "StdHepSelectMask " << selectmask;

By default, StdHepSelectMask is set to PTSim::kMomentum.

Configuration options StdHepThr and StdHepThrByType

The momentum threshold applied to secondaries can be adjusted using the StdHepThr parameter. For example, to specify a threshold of 0.20 GeV/c, use:

The default StdHepThr momentum threshold is 0.15 GeV/c. Note that this threshold is only used if the user has enabled selection mode PTSim::kMomentum in the StdHepSelectMask.

The momentum threshold can also be adjusted by secondary ``type'' using the StdHepThrByType parameter. The ``type'' is the production mechanism and/or the PDG id of the secondary particle, where the production mechanism is one of the list of UtilIstHEP::EProdMethod enumerated mechanisms shown in Table 21.5.1.

The format for specifying a momentum threshold by type is:

  .Cmd("StdHepThrByType <pthresh(GeV/c)> <mechanism type> <particle id>");
A momentum threshold specified by type will override the default momentum threshold set by StdHepThr for the specified type.

For example, to specify momentum threshold 0.01 GeV/c for those particles produced by Bremsstrahlung:

std::ostringstream oss;
oss << "StdHepThrByType " << 0.01 << " " << UtilIstHEP::kMBrem;

As a second example, to specify momentum threshold 0.01 GeV/c for positrons produced by any mechanism, one would use:

std::ostringstream oss;
oss << "StdHepThrByType "<< 0.01 <<" "<< UtilIstHEP::kMNoProcess <<" "<< -11;

The third and final example specifies momentum threshold 0.30 for electrons produced by Delta Ray production:

std::ostringstream oss;
oss << "StdHepThrByType "<< 0.30 <<" "<< UtilIstHEP::kMDeltaRay <<" "<< 11;

By default, the StdHepThrByType momentum thresholds are set to zero for:

Configuration option StdHepHitThr

The parameter StdHepHitThr can be used to adjust the hit energy threshold for determining when a secondary resulting in an energy deposition hit is to be selected for storage. For example, to set the hit energy threshold to 0.002 GeV one would use:

The default hit threshold is 0.001 GeV. Note that this threshold is only used if the user has enabled selection mode PTSim::kHit in the StdHepSelectMask.

Configuration option StdHepSaveSibling

The parameter StdHepSaveSibling can be used to specify if siblings of selected secondaries should also be selected for storage to the output StdHep array. Siblings are particles generated in the same production mechanism event, such as decay products from a single decay. For example, use:

to disable the storage of selected secondary sibilings. The default value is 1 (enabled).

next up previous contents
Next: About this document ... Up: The MINOS Off-line Software Previous: Minos Event Display (sub)   Contents
MINOS Software 2015-09-21