General GMINOS Info

Presently Minos detector interactions are simulated using the GMINOS package, a FORTRAN/CERNLIB/GEANT3 based detector simulation for the Minos detectors. General info on GMINOS can be found here. Presently a scheme a vegetable names is being used to tag version of the gminos executable. The vegetable releases are in alphabetical order. GMINOS is controlled by something called an FFR card, which contains all of the desired options for a given run. This can inlcude things like the detecor geometry, the b-filed, the type of interactions, etc. You can look at the documentation on the Geometry FFR settings , the Program Control FFR settings , or the Neugen3 FFR settings. You can also find example of an ffr card used to simulate beam events, by running gminos_jobs.

Output of GMINOS

The output of GMINOS are fz_gaf files that contain information about "hits". Note in this context a hits is merely information that a certain paricle deposited a certain amount of energy in a certain place in the detector. In general this is not very useful, as it does not tell you how much charge is desposited on a PMT channel. The next step is to convert the fz_gaf file into a reroot file. This reroot file is merely a root-compatible version hit information in the fz_gaf file. Don't be confused by the .root at the end of the name. This file does not contain reconstructed events.

Now you are all set to run the events through loon. In loon there are few things that you must do to the events. First you must convert the hit information (which again just tells you about energy deposition) into photons and you must figure out how many photons actaully strike the PMTs. This is done in the PhotonTransport module. Then the photons must be digitzed and the readout of the detector electronics is simulated in DetSim. Then you can finally reconstruct the events with your favorite reconstruction package. See the User's Manual for more info on running the offline software. For an example of how to configure a loon jobs to run on an MC file, you could look at the batch group's web pages , where you will find links to the actual job scripts used to reconstruct MC files in the official batch processing.

Simulating Beam Neutrino Events

For the gory details, you really should see gminos_jobs.

But to summarize, to generate beam MC events, the first step is to obtain the neutrino beam flux files. These are paw ntuples, that are produced by GNuMI. These are presently stored in AFS space at /afs/fnal.gov/files/data/minos/d87/gnumi. For the far detector is is fairly straightforward to simulate single neutrino interactions. For the near detector the situation is more complicated. The near detector typically has dozens of neutrino interactions per beam spill inside the detector, and there are also numerous CC interactions of muon neutrinos in the rock that produce muons. If these muons are high enough in energy they can enter the near detector through the front face or the sides. So, for the near detector, one first should generate single detector events. (That may be sufficient for your purposes.) You can also generate files of just rock events. The rock events take a really long time to run, since a large area of rock must be considered. Typcially in MC production we generate a smaller sample of rock-only events and reuse them.

The final step is to overlay the single detector events and the signle rock events into snarls (or spills). This is done using a program call reco_minos. During that process, detector events and rock events are randomly distributed over an 8.9 microsecond time window and are reassmbled into one record. Just as is the case with the data, it is then up to the reconstruction software (such as the slicer or the chopper) to try to separate the snarl hits into individual neutrino events. The other complication about the overlay process is that the user must tell reco_minos how many detector events and rock events (on average) to put into each snarl. In order to have some know these numbers to a high degree of accuracy, the user must first generate a large sample of detector events and rock events. (As is described in the gminos_jobs documentation, these numbers can be found by examining the log files.)

Simulating A Single Particle Type

If you are interested in beam neutrino interactions, see the previous section. But if you would like to study one particle type, such as single muon, with a given momentum, starting at a specific location in the detector, you can accomplish this by adding a few control lines to the FFR card. For example, the following lines will cause gminos to generate muons, with a momentum of 5.0 Gev alon the z-axis at (0.5cm,0.5cm,2.0cm). Note that the units her are cm. Also the coordinates are the hall coordinates, not the detector coordinates. For the near detecor, the detector zero (the first plane) is at z=4907.2 cm relative to the hall. For the far detector, the z=0 of the detector is at z=1402.2 cm relative to the hall.
c Set MKIN=3 to generate a single particle type
C Now set the particle type in the GEANT code
C and the x,y,z momentum and start position
KINE 6 0.0 0.0 5.0 0.5 0.5 2.0

Here is an example of a FFR card for a single particle type.

Simulating Standard HEP events

If you want to simulate a particular type of interaction or decay with a particular type of kinematics, over a range of initial positions and momenta, you can also create a StdHEP data file and then input that into GMINOS. If you don't have one already is an example of an FFR card that uses a StdHEP file. The important features are the lines
Setting MKIN to 1 means that GMINOS will look for a file called "hepevt.dat", and read in the initial particle list from there. Now you need to understand the hepevt format. Each event consists of multiple partciles. Each event entry begins with a line giving the event number and the total number of particles contained in that event. After that, there is one line for each particle in the event. The line has 15 fields, explained in the table below:
Field Number Description
1 Stauts code 3=incoming particle (neutrino in our case) , 1= final state particle
2 Particle Code (in the PDG standard format)
3 Line # of first mother particle in the event, relative to event start (0 for initial entries)
4 Line # of second mother particle in the event, relative to event start (0 if there is only one mother)
5 Line # of first daughter particle in the event, relative to event start (0 if it hasn't decayed)
6 Line # of final daughter particle in the event, relative to event start (0 if it hasn't decayed)
7 x momentum (in GeV/c)
8 y momentum (in GeV/c)
9 z momentum (in GeV/c)
10 energy in GeV
11 mass in GeV/c**2
12 initial x position, in mm
13 initial y position, in mm
14 initial z position, in mm
15 production time, in mm/c
Note that you need need to have at least one entry of status=3. Typically I make it a neutrino and treat it as a dummy particle. Then the final state particles, with status 1 are the particles that GMINOS will actually track. Note that the x,y, and z coordinates are relative to the detector hall, not the the front of the detector. For the near detector, there is a z-offset of 49072 mm between the hall front and the detector face. For the far detector there is a z-offset of 14022 mm between the hall front and the detector face. So, for example, an entry for a muon, with a momentum of 5 Gev along the z-axis, starting a 1mm,1mm,1mm would look like:
1 2
3 13 0 0 2 0 0. 0. 5.0 5.0011 0.105 1.0 1.0 1.0 0.0
1 14 1 0 0 0 0. 0. 5.0 5.0011 0.105 1.0 1.0 1.0 0.0
The next entry, say for a muon with an intial position of (1mm,1mm,2mm)would look something like
1 2
3 13 0 0 2 0 0. 0. 5.0 5.0011 0.105 1.0 1.0 2.0 0.0
1 14 1 0 0 0 0. 0. 5.0 5.0011 0.105 1.0 1.0 2.0 0.0

NOTE: The hepevt.dat files is NOT in ascii!!!! It is a fortran binary file. So, to produce it, at some point you need a FORTRAN program that will write the info out to an unformatted output file. (Don't panic. Fortran will make you strong.) I've put an example of a FORTRAN routine that generates a hepevt.dat file for monoenergetic muons, which you can modify to suit your needs. To compile it you will have to do something like: g77 -o generate_hepevt generate_hepevt.F -L$CERNLIBS -lkernlib.
Have fun!
Return to the MC Working Group Page.