110 likes | 229 Views
MINOS Software. Liz Buckley-Geer. Overview. MINOS uses ROOT as the basis of its offline software All new code is C++ Not much use of templates yet or STL containers mainly related to the use of ROOT Using SRT Mostly Linux (RedHat with a few rogues - Debian). Have an SGI at FNAL
E N D
MINOS Software Liz Buckley-Geer
Overview • MINOS uses ROOT as the basis of its offline software • All new code is C++ • Not much use of templates yet or STL containers mainly related to the use of ROOT • Using SRT • Mostly Linux (RedHat with a few rogues - Debian). Have an SGI at FNAL • Using gcc 2.91 at most university sites but gcc 2.95.2 at FNAL • Not using UPS/UPD • Doesn’t currently make use of any ZOOM or CLHEP packages • Detector simulation is still done using Fortran package + Geant 3 • Monte Carlo truth information is stored in Adamo tables and converted to equivalent ROOT classes using a converter program
Overview • Code is organized into modules • Modules invoke Algorithms which construct Candidates • Candidates are the event classes - there are a set of base reconstruction classes for things like tracks etc that inherit from Candidate • Algorithms do things like reconstruct muon tracks and hadron showers • Database will be Oracle eventually at FNAL and Soudan but probably MySQL for off-site users. Currently using MySQL everywhere.
Components - written by MINOS • Job Control • Controls module flow and configuration of modules and algorithms. Specifies input/output data files. • Message Service • Basically does what ErrorLogger does. Author did not know of the existence of the ZOOM product at the time he wrote the package • Navigation • Tools for iterating over transient data objects • Lattice • Manages relationships between two transient objects - is not persistable
Components cont’d • Candidate • Base classes for reconstructed objects • Algorithm • Base class for reconstruction algorithms. Algorithms are invoked from the constructor of the Candidate • Various algorithms exist for track finding, electron id etc • Geometry-like information • Validity - manages time validity of parameters • UgliGeometry - unified geometry access • Plex - logical connections between detector elements, channel number to scintillator strip for example • Bfield - magnetic field lookup package
Components cont’d • IoModules/Persistency • Gets data in and out of the framework. Data stored in ROOT Ttrees • DatabaseInterface • Interface to database. Uses RDBC which is a ROOT interface to ODBC. RDBC written by Valeriy Onuchin - IHEP. • RawData • Definition of raw data classes • Rotorooter • Writes ROOT files from the DAQ system • MIDAD • Event display - don’t ask about the name!
Components cont’d • Neugen • Rewrite of the SOUDAN2 Monte Carlo in C++ • Had one review of the design with a number of CD + MINOS reviewers (Lynn Garren, Mark Fischler, Marc Paterno and Panagiotis Spentzouris) in April • Lots of feedback from reviewers • Hugh Gallagher felt the review was very helpful • Hugh plans to make this package independent of MINOS - will provide interface to MINOS framework much like CDF interfaces to HERWIG for example. • Trying to decide what external tools to use, STDHEP++, ZOOM etc. Hasn’t made a final decision yet.
Main players • Stanford University • George Irwin (leader of software effort) • Robert Hatcher - RawData, Geometry, Fortran detector simulation • Harvard • Mark Messier - JobControl, MessageService, IoModules • Roy Lee - tracking reconstruction, Reco bases classes • Students • Oxford • Nick West - Navigation, Lattice, DatabaseInterface • Students • University of Minnesota • Sue Kasahara - Persistency, online data dispatcher • Pete Border - Mr. Database • John Urheim (overall Computing Level 2 manager) • Hugh Gallagher - Neugen
Main Players cont’d • BNL • Brett Viren - event display (MIDAD) • IHEP • Valeriy Onuchin - RDBC • Indiana University • Brian Rebel - Demultiplexing algorithms for far detector
Immediate future • There is a test beam run at CERN using a Calibration detector which is a small version of the real thing with the same scintillator, steel and electronics. • Cosmic ray data is being taken now and beam will arrive in mid-August. • Various parts of the software are needed for this run, things like writing ROOT files from DAQ, access to the database, event display, geometry information to allow reconstruction of data, tracking algorithms etc. • Most of this is in place at some level. The geometry-like info is currently on the critical path and should be done in a few weeks.
Later this year • Constructions of the far detector begins in August. As the planes are erected they will be read out. At some point there will be enough planes to start doing useful things with cosmic ray data. • Plan on having a series of “post-mortem” reviews of the software packages in the fall as a result of feedback from the Calibration detector users. • I am worried that we have too much home grown stuff and a very small team to maintain it so I would like to see more use of existing tools if possible.