There are several areas in which prototypes were developed before proceeding with an accepted direction
Historically, the transition from Fortran to C++ lost the input/output abilities ("persistency"). Two examples of persistent object store mechanisms have come into recent use: Root and Objectivity. Objectivity requires too much support and maintenance for our resources, so Root was the remaining candidate. It was successfully used for the 1999-2000 BTEM test. It satisfied our needs for a structured output of objects. We also made use of Root's capabilities for analysis (access to the data, histogramming, fitting etc). This was also shown to fit our needs, though our lack of experience with the product showed itself in the limited ways we were able to use Root. See X for a fuller description.
Early in GLAST's development, it was decided to go fully C++. This also included development and support of a fully C++ simulation package for following particle trajectories and interactions in complex geometries, since none existed at the time. In essence, a package was constructed to supply similar features to those provided by GEANT3, with some improvements in the geometry handling. This new package, Gismo, has been in use for several years now, and has proved adequate to the task of designing the instrument and interpreting test beam data. See X for a fuller description.
While Gismo has proven adequate for the instrument design and reasonable agreement with test data, it suffers from a major deficit: it is unique to GLAST. As it stands, it is supported (and understood) by a single person and is mostly undocumented. GEANT4, the replacement for GEANT3, is in the late stages of development now and is sure to become the world standard in this area, as its predecessor was. It is much better documented, supported by a large collaboration, and is coming into wide use in the community. It was decided to use G4 as the simulation package for the 2001 BFEM program as a prototype. We have seen that it can well describe the instrument and have done validations, as described in X, indicating that G4 is up to the task.
As for the simulation tools, a reconstruction package has been part of the GLAST development toolkit for some years and has provided great insight into the problems.
The event reconstruction breaks down into three coupled components: finding tracks and photon candidates in the TKR; estimating the energy and enhancing the background rejection in the CAL; and rejecting charged particle backgrounds in conjunction with TKR tracks in the ACD.
For the CAL this means optimizing the energy resolution and maximizing the effective area. Additional background rejection power can be obtained from discriminant variables based on shower moments, topology and clustering. The CAL can operate in concert with the TKR (in its guise as a sampling calorimeter) to improve the PSF at low energies. Finally the CAL can provide energy and direction information for high energy CAL-only interactions.
More details can be found X.
For a code system as large and complex as needed for the simulation and reconstruction, a code framework is essential. It supplies basic rules of behaviour for modules; philosophy for dealing with data and algorithms; interface strategy for in-memory ("transient") classes versus on-disk ("persistent") versions; and services for useful utilities (like messaging, random number handling and so on). A promising candidate, Gaudi - developed for the LHCb experiment at CERN's upcoming LHC collider, has appeared. It has now been extended for use by several collaborations and is Open Source, so it is no longer specific to LHCb. As, for GEANT4 and Root, it is now has a wide community of users and is well documented. Our initial prototype was to make use of Gaudi's data and algorithms base classes; use Root for a persistent store (using supplied conversion macros); and adopt the messaging and random numbers service, all for a revised version of the simulation and reconstruction code. The success of that prototype led us to adopt Gaudi as our framework. More details are presented at X.
When interpreting the raw data, the reconstruction process will need to convert electronic readouts to physical units. This will involve scale factors (gains) and offsets (pedestals) in the CAL and ACD, and strip positions (alignment) and hot/dead strip lists in the TKR. These conversion and alignment factors will change over time as the instrument ages. A system must be devised to allow access to these constants, using time as an index. An initial prototype was devised to use a relational database (MySQL) to hold meta-data describing times of validity and pointers to calibration files. The issues involved were the richness of the database to describe the meta-data and the ability to access it from running processes. Such databases are in wide use in HEP experiments, so it was no surprise that this mechanism should work for us too. Details are presented at X.
R.Dubois Last Modified: 06/28/2001 13:23