The ATLAS Software Framework

The software for the experiment is developed by a working group, comparable in manpower to a subdetector working group in hardware. The complexity of the detector also implies the complexity of the underlying software and hence it requires to develop a common software framework for the experiment which is calledAthena_[54].

Athena_{provides several features. First of all, it allows an integrated communication between} various software applications - called algorithms - within the framework. All algorithms have access via the so-calledStoregate _{to data of other algorithms, e.g. the event information}6

or the detector description. Moreover, a common framework ensures a common approach 6_{the information of one proton-proton collision}

4.4. ATLAS COMPUTING 35

Figure 4.18: Illustration of theAthena _{Monte Carlo software chain and the}

corresponding Muon Software validation chain, which is discussed in detail in appendix A.

of software developing, e.g. messaging or access on disk and re-use of already written code- segments, i.e. a common underlying design of the software packages. TheAthena_framework allows a dynamic loading of libraries and is organized in form of plug-in modules and allows a flexible configuration of various algorithms which should be executed. The configuration is done via the so-called JobOption_{file which allows a user specification of the algorithms via} Python _scripting.

The main purposes of the ATLAS software is to generate, simulate, digitize and reconstruct proton-proton collisions, i.e. events, in the LHC environment. This Athena _{software chain} is illustrated in Figure 4.18. Thus the advantage of the modular approach becomes obvious at this stage since the simulation, digitization and reconstruction algorithms for the sub-detector systems, i.e. Inner Tracker, Electromagnetic Calorimeter, Hadronic Calorimeter and Muon Spectrometer, can be implemented by the corresponding development teams independently from each other.

The generation step includes the proton-proton collision itself, i.e. calculating the position and momentum four-vectors of all particles which are produced in the collision7

. The gen- eration is based on various Monte Carlo generator programs, which are briefly discussed in section 2.3.

The second part is the tracking of the produced particles through the detector using the Geant4_{toolkit [55].} Geant4_{simulates the impact of the magnetic field and the interactions} with the material, e.g. multiple scattering, energy loss, photon conversions and further decays of unstable particles. Each interaction of a particle with an active, i.e. sensitive, detector element is stored in a so called hit-object, which represents the position and type of the interaction.

During the digitization step, the response of the detector and its electronics on the various 7

The four-vector information, coming from the Monte Carlo generator programs, is called Monte Carlo truth information in the following

36 CHAPTER 4. THE ATLAS EXPERIMENT hit-objects is simulated. As an example the interaction between a final state muon in the gas-volume of an MDT-chamber is discussed. The muon interacts with the gas at several positions and hence these positions are stored in hit-objects. During the digitization, the hit-object with the closest distance to the wire is used for the calculation of the drift-radius, which is converted to a measured drift-time, assuming a certain resolution for a single MDT- tube. The drift-time information is stored in a so-called digit-object, which also stores the information about the associated tube and MDT-chamber.

The reconstruction part is based on the digitized information, i.e. in the above example on the simulated drift-time or in case of data on the measured drift-time for each tube. The reconstruction includes various algorithms, e.g. for pattern recognition, track fitting, vertex determination and energy measurements. It should be noted that the digitized information and the real data are equivalent from a data representation point of view.

The output of the reconstruction part are so-called event summary data (ESD) and analysis object data (AOD) files. While the first include a more detailed description of an event, e.g. the drift-radius information which was used for the track reconstruction, the latter one, only include information which is of primal interest for physics analysis, e.g. the charge or the momentum of particles.

The last step in a standardAthena_{chain is the actual physics analysis, where several analysis} techniques can be applied to study a particular physics process.

It should be also mentioned, that ATLAS software provides an event display, calledAtlantis_, which presents an event graphically. Such a tool is useful not only for the visualization of events but also for the validation of the reconstruction algorithms and detector geometry description.

The simulation and reconstruction step require a common basis of the detector description, which should include a description of the geometry, the positioning and the material of the detector elements. This common source of the detector description is calledGeoModel_[56]. This ensures that each step is based on the same detector information which prevents the algorithms from inconsistencies. The corresponding data of theGeoModel _{are stored in a} database. A crucial point is that all alignment algorithms are also based on theGeoModel description. Hence, applying alignment algorithms on real data, will lead to an adjusted database, which is a new basis for the reconstruction of data.

All objects inGeoModel _{are recursively defined by adding or subtracting geometric prim-} itives, e.g. cubes or cylinders. The description of a part of the torodial magnet system is shown in reality and in the GeoModel _{description as an example in Figure 4.19. A} material description is assigned to each component within GeoModel_{, which is accessible} for the reconstruction and the Geant4 _simulation. GeoModel _{allows also the handling} of time-dependent positioning of all detector-elements, which is especially important for the alignment of 1.200 MDT-chambers in the Muon Spectrometer.

It is obvious, that a valid description of the detector within GeoModel _{and the validation} of the Athena _{software chain, starting from generation to reconstruction, is crucial for all} physics analysis. A significant part of this thesis was to provide a corrected description and tools for the validation of the software chain. A brief overview is given in Appendix A, a more detailed description has been published in [3, 8].