750
D. Froidevaux
The main requirement on the computing model is to provide prompt access to all
the data needed to carry out physics analyses. This typically translates to providing
all members of the collaboration with access to reconstructed data and appropriate,
more limited, access to raw data for organised monitoring, calibration and alignment
activities. As already mentioned, the key issue is the decentralisation and wide
geographic distribution of the computing resources. Sharing of these resources is
possible through the Grid and its middleware, and therefore the interplay with the
Grid is built into the models from the very beginning.
The most important elements of the computing model are the event data model
and the flow of the various data types to the analysis processes.
16.7.1.1 Event Data Model
The physics event store contains a number of different representations, or levels
of detail, of the physics events from the raw (or simulated) data all the way to
reconstructed and summary data suitable for massive fast analysis. The different
types of data are:
• Raw data: this is the byte-stream output of the High-Level Trigger (HLT) and
is the primary input to the reconstruction process. The ATLAS experiment
expects ≈1.5 MB of data arriving at a rate of ≈200–300 Hz. Events are transferred from the HLT farm to the Tier-0 in 2 GB files containing events from
a data-taking period with the same trigger selections from a single LHC fill.
The events will generally not appear in a consecutive order, since they will have
undergone parallel processing in the HLT farm beforehand.
• Reconstructed data (referred to as Event Summary Data or ESD): this is the
output of the reconstruction process. Most detector and physics studies, with the
exception of calibration and alignment procedures, will only have to rely on this
format. The data are stored using an object-oriented (OO) representation in socalled POOL-format files [31, 32]. The target size for the ESD files has increased
from 500 to 800 kB per event over the past few years.
• Analysis Object Data or AOD: this is derived from the ESD format and is a
reduced event representation, intended to be sufficient for most physics analyses.
The target size is roughly a factor five smaller than that of the ESD (i.e. 100–
200 kB per event) and the contents are physics objects and other high-level
analysis elements.
If experience from the Tevatron and initial experience from the experiment
commissioning and early data-taking phase are used as a guide, it is expected that
in the early stages of the machine and experiment commissioning the ESD format
will be in heavy use. The AOD format is expected to become the dominant tool for
studies only when both machine and experiments are in steady-state data-taking.
Nevertheless, it is planned to commission the AOD format with real collision data
as early as possible, since one of the biggest constraints on the computing model
will be the access bandwidth to the data. The AOD, in addition to being the format
D. Froidevaux
The main requirement on the computing model is to provide prompt access to all
the data needed to carry out physics analyses. This typically translates to providing
all members of the collaboration with access to reconstructed data and appropriate,
more limited, access to raw data for organised monitoring, calibration and alignment
activities. As already mentioned, the key issue is the decentralisation and wide
geographic distribution of the computing resources. Sharing of these resources is
possible through the Grid and its middleware, and therefore the interplay with the
Grid is built into the models from the very beginning.
The most important elements of the computing model are the event data model
and the flow of the various data types to the analysis processes.
16.7.1.1 Event Data Model
The physics event store contains a number of different representations, or levels
of detail, of the physics events from the raw (or simulated) data all the way to
reconstructed and summary data suitable for massive fast analysis. The different
types of data are:
• Raw data: this is the byte-stream output of the High-Level Trigger (HLT) and
is the primary input to the reconstruction process. The ATLAS experiment
expects ≈1.5 MB of data arriving at a rate of ≈200–300 Hz. Events are transferred from the HLT farm to the Tier-0 in 2 GB files containing events from
a data-taking period with the same trigger selections from a single LHC fill.
The events will generally not appear in a consecutive order, since they will have
undergone parallel processing in the HLT farm beforehand.
• Reconstructed data (referred to as Event Summary Data or ESD): this is the
output of the reconstruction process. Most detector and physics studies, with the
exception of calibration and alignment procedures, will only have to rely on this
format. The data are stored using an object-oriented (OO) representation in socalled POOL-format files [31, 32]. The target size for the ESD files has increased
from 500 to 800 kB per event over the past few years.
• Analysis Object Data or AOD: this is derived from the ESD format and is a
reduced event representation, intended to be sufficient for most physics analyses.
The target size is roughly a factor five smaller than that of the ESD (i.e. 100–
200 kB per event) and the contents are physics objects and other high-level
analysis elements.
If experience from the Tevatron and initial experience from the experiment
commissioning and early data-taking phase are used as a guide, it is expected that
in the early stages of the machine and experiment commissioning the ESD format
will be in heavy use. The AOD format is expected to become the dominant tool for
studies only when both machine and experiments are in steady-state data-taking.
Nevertheless, it is planned to commission the AOD format with real collision data
as early as possible, since one of the biggest constraints on the computing model
will be the access bandwidth to the data. The AOD, in addition to being the format