a framework for the GEANT3 based simulation of MINOS (and any other sandwich active-passive plane neutrino detector). It supplies a means of configuring the geometry via data cards, selecting neutrino flux from a variety of methods, calling event generators (neutrino and cosmic muons), passing the events to GEANT3 for tracking, recording hits (truth), generating digitizations (detector response) and storing them with the initial event into ADAMO data structures/files. MINOS specific digitizing routines exist for simulating the two electronics configurations.gminos incorporates the neugen cross-section and event generation routines into it's binary along with means of sampling neutrino fluxes in order to make a complete detector simulation. It also has hooks for processing pre-generated events (i.e. stdhep data files) within the MINOS detector and can be extended for alternative event generation. gminos, like GEANT3 on which it is based, uses the FFREAD package for configuring a run using text based "data cards".
Additional info can be found in links referenced from the the labyrinth (http://www-numi.fnal.gov/fnal_minos/computing/labyrinth/index.html) page and various NuMI notes:
I've done a cursory test of the differences between gheisha and fluka.
For most of its existence gminos could only modify the neutrino flavor by swapping the flavors in a fixed mapping independent of energy. In the last year (2002-05-24) David Petyt's oscillation code was incorporated and one can generate event files for fixed oscillation scenarios. Doing so isn't so useful in reconstruction algorithm development or testing, but it might be useful to create a (series of) event sample(s) of undisclosed parameters and allow users to attempt to extract them.
The simplest means of getting set up to run is to find a site with the labyrinth already installed (e.g. any FNAL linux or SGI machine with ups and AFS). Sourcing the site setup script will setup the environment variables and add $LABYRINTH_BIN to the $PATH; on FNAL this can be found at:
/afs/fnal.gov/files/code/e875/sim/labyrinth/setup_labyrinth.[c]sh
If one doesn't have simple access to an already installed site, one can install the labyrinth by following the instructions found under the labyrinth page.
$ setenv GMINOS_FFR datacards.ffr
$ gminos_batch >& output.log &
Generating LE beam far detector events on a 1.1GHz laptop takes roughly 1.3 sec/each (~9hrs for 25000 events); time will obviously scale down with processor speed and up with average event energy. While running gminos_batch will periodically update the one line text file gminos_status.processid. This allows one to see how many events have been processed. Removing the file signals the job to end gracefully.
This process generates records in a ADAMO file. The records contain single neutrino interactions. For the near detector with pile up and incoming muons from the rock one must re-sample this file to produce a new one with several interactions per record -- this sampling will depend on knowing the POTs in a spill to calculate the average number of events. Details can be found at http://home.fnal.gov/~rhatcher/gminos/near_det.html. The output of this step is identical in form as the initial gminos ADAMO file
To then convert this file to a "reroot" file one can use with the offline C++ framework one must:
$ cp $SRT_PUBLIC_CONTEXT/Rerootjob/reco_options ./reco_options
$ echo datafile.fz_gaf > reco_minos.gaf_list
$ rerootjob -n nevts
$ mv reroot.root datafile.root
$ loon movie_reroot.C reroot.root
|
MINOS_DATA=/afs/fnal.gov/files/data/minos
An initial offering is:
$MINOS_DATA/d06/detsim01/ph2le/gm_far_le_numu_1_hapr01.rootwhich is a reroot'ed file (643 Mbytes) of 25,000 unoscillated neutrino events in the far detector. This is with an older LE beam spectra (and nue contamination) and no fiducial volume cuts.
The tape robot data can be retrieved using ftp (or the pnfs interface on minos1.fnal.gov) as described in http://www-numi.fnal.gov/minwork/computing/getting_data.html. While at this time there is not accurate/maintained catalogue of files, one should just look to see what exists. Filenames usually describe the contents of the files using reasonable guesses. If a reroot file doesn't exist, consider whether an ADAMO (file extension fz_gaf) one does; instructions for converting it are given above.
The major steps necessary for digitization have been presented at various meetings and the basics objects (photons, pe's, signals, etc) are straighforward. Both Mark Messier and Robert Hatcher have ideas about how to construct a framework for making the individual steps independent (allowing experts to write simulation code for their part of the chain, e.g. PMT cross-talk). This is a high priority item (except when it gets pushed aside by the daily critical interuptions). Progress should really become visible in the next few months.
Once digitization has been moved then we can consider any move to Geant4. This isn't so pressing because while there might be a general unhappiness with gheisha and/or fluka, the hadronic physics in Geant4 hasn't been well validated. (The devil you know...). An intriguing possiblility is the ROOT team's development of a new geometry modelling scheme. We want to migrate our current geometry over to this new package for various reasons. The ROOT team has proposed and are working towards a means of using thier geometry in conjunction with Geant4, and (modern) fluka. This would mean their own driver for swimming that calls the ROOT geometry and the Geant4/fluka physics. This would allow us to use the same geometry for simulation as we use in reconstruction without resorting to translation or duplication. The time scale for the ROOT integration is probably on the order of a year, which is acceptable given our plans for migration to the new geometry and any need to migrate to Geant4
No part of this migration should seriously interfere with the development of reconstruction algorithms. The raw DAQ data will improve in how well it mimics the real detector, and the ability to correlate digitizations to hits will be reinstated (was available in a limited manner in the FORTRAN framework). The enhancements gained by the migration might allow a better determination of how to deal with pathological cases and other refinements to algorithms. The information regarding the incoming neutrino/target and primary particle lists does exits, has to exist, but the details of how it is stored are subject to change.