16 Integration of Detectors into a Large Experiment: Examples from ATLAS. . .
753
the code development. The usual issues which result from relying on multiple
institutions and funding agencies have risen here as well (see Sect. 16.2).
• Another major issue has been the maintainability of the systems. Given the
expected long lifetime of the LHC programme, it was deemed necessary, from
the very beginning, that the software systems be built using object-oriented
methodologies. The C++ programming language has been chosen as the major
development tool.
At the heart of the software system of the experiment is the software framework,
which provides support for all the data-processing tasks. All such tasks, including
the simulation, reconstruction, analysis, visualisation, and, very importantly, the
high-level trigger operate within this framework. It provides the basic software
environment in which code is developed and run, as well as all the basic services
(e.g. access to calibration and conditions data, input/output facilities, persistency, to
name but a few examples).
All the applications, which are built on top of the framework use a component
model, i.e. they have building blocks, which appear to the framework as standard
plug-ins. The main advantage of the component model is the factorisation of any
one solution into a number of independent software codes, but also a significant
flexibility to adapt to changes in the future. The final major architectural and design
principle has been the separation of algorithms from the data and the acceptance of
different data representations in memory (transient) and file storage (persistent).
16.7.3 Analysis Model
As has been already mentioned, the ESD and AOD/DPD formats are the primary
tools for carrying out physics studies. Both formats are stored in POOL files and
are processed using the respective software framework of each experiment. The
decreasing event size in the event model allows the users to process a much larger
number of AOD/DPD events than ESD events. In addition, the AOD/DPD formats
will be more accessible, with a full copy at each Tier-1 site and large samples at Tier2 sites. It is therefore expected that most analyses will be carried out on AOD/DPD
data.
To illustrate the ATLAS analysis model with a concrete example, a specific
analysis task may begin with a query against the TAG data to select a subset of events
for processing using a suitable DPD format. This query might be for events with two
leptons, missing transverse energy and at least two jets, all above certain thresholds.
The result of this query is then used to define a dataset (or set of files) containing
the information for these events. The analysis would then proceed to make further
event selection by refining various physics quantities, e.g. the muon isolation or
the missing transverse energy calculation. The fine-grained details of how much
processing and event selection will be carried out by individuals versus organised
physics groups (e.g. the Higgs group) is not frozen yet. It is widely expected that
753
the code development. The usual issues which result from relying on multiple
institutions and funding agencies have risen here as well (see Sect. 16.2).
• Another major issue has been the maintainability of the systems. Given the
expected long lifetime of the LHC programme, it was deemed necessary, from
the very beginning, that the software systems be built using object-oriented
methodologies. The C++ programming language has been chosen as the major
development tool.
At the heart of the software system of the experiment is the software framework,
which provides support for all the data-processing tasks. All such tasks, including
the simulation, reconstruction, analysis, visualisation, and, very importantly, the
high-level trigger operate within this framework. It provides the basic software
environment in which code is developed and run, as well as all the basic services
(e.g. access to calibration and conditions data, input/output facilities, persistency, to
name but a few examples).
All the applications, which are built on top of the framework use a component
model, i.e. they have building blocks, which appear to the framework as standard
plug-ins. The main advantage of the component model is the factorisation of any
one solution into a number of independent software codes, but also a significant
flexibility to adapt to changes in the future. The final major architectural and design
principle has been the separation of algorithms from the data and the acceptance of
different data representations in memory (transient) and file storage (persistent).
16.7.3 Analysis Model
As has been already mentioned, the ESD and AOD/DPD formats are the primary
tools for carrying out physics studies. Both formats are stored in POOL files and
are processed using the respective software framework of each experiment. The
decreasing event size in the event model allows the users to process a much larger
number of AOD/DPD events than ESD events. In addition, the AOD/DPD formats
will be more accessible, with a full copy at each Tier-1 site and large samples at Tier2 sites. It is therefore expected that most analyses will be carried out on AOD/DPD
data.
To illustrate the ATLAS analysis model with a concrete example, a specific
analysis task may begin with a query against the TAG data to select a subset of events
for processing using a suitable DPD format. This query might be for events with two
leptons, missing transverse energy and at least two jets, all above certain thresholds.
The result of this query is then used to define a dataset (or set of files) containing
the information for these events. The analysis would then proceed to make further
event selection by refining various physics quantities, e.g. the muon isolation or
the missing transverse energy calculation. The fine-grained details of how much
processing and event selection will be carried out by individuals versus organised
physics groups (e.g. the Higgs group) is not frozen yet. It is widely expected that