626
M. Delfino
The production workflows involve a number of tasks, 55 such as event reconstruction, simulated event production, data reduction, event filtering, and calibration data
processing.
14.4.1 Event Reconstruction
Data arriving from an experiment’s data acquisition system is called “raw” data. It
is organized in “event records”, each record corresponding to a particle interaction
“event” which is relevant in the context of the experiment. An event record may or
may not correspond to a single collision between particles, though particle physicists
often refer to data arising from a single collision as “an event”. In a collider, an
event record may correspond to data collected from a single beam crossing, which
depending on the beam type, luminosity and angular coverage may contain data
arising from several particle collisions. 56 In a fixed target experiment an event
record may correspond to data collected over a full beam spill. In an astroparticle
experiment an event record may correspond to data collected starting from a trigger
signal for a certain length of time. Furthermore, due to performance requirements
of data acquisition systems, raw data is often compressed, encoded or packed into
rather complex data structures, which are often not very convenient for direct use in
reconstruction programs. Therefore, a raw event record is usually read from disk and
immediately “unpacked” into simpler but larger data structures where the digitized
signals are represented by standard integer or floating point numbers.
The output of the most complete simulations (often called “full” simulations,
see below) can be stored in “packed raw” format identical to the detector data, or
in “unpacked raw” format in which case the unpacking step is omitted in reading
simulated event records. 57 Thereafter, simulated event records are treated identically
to detector “real” data.
A number of event records are written by the data acquisition system to a raw
data file, which is the main data item delivered from the “online” to the “offline”
environment. The organization of event records into raw data files is very often
unrelated to the experimental conditions and simply reflects technical constraints
such as the size of disk buffers in the online and offline clusters.
55 The names of these tasks are not standardized. Therefore readers will have to identify the
corresponding task names for their respective project.
56 In electron-positron collisions there is a single collision most of the time, but there may be
occasionally an annihilation event together with a two-photon collision, for example. In proton–
proton collisions there are on average 20 collisions per beam crossing at the nominal luminosity of
the original LHC configuration.
57 Even though it would be more economical to store simulated data in “packed raw” format, this is
often not possible. For example, the simulations may be needed before the detector data acquisition
system is fully designed and implemented, and therefore the exact format for packed raw data will
not be known.
M. Delfino
The production workflows involve a number of tasks, 55 such as event reconstruction, simulated event production, data reduction, event filtering, and calibration data
processing.
14.4.1 Event Reconstruction
Data arriving from an experiment’s data acquisition system is called “raw” data. It
is organized in “event records”, each record corresponding to a particle interaction
“event” which is relevant in the context of the experiment. An event record may or
may not correspond to a single collision between particles, though particle physicists
often refer to data arising from a single collision as “an event”. In a collider, an
event record may correspond to data collected from a single beam crossing, which
depending on the beam type, luminosity and angular coverage may contain data
arising from several particle collisions. 56 In a fixed target experiment an event
record may correspond to data collected over a full beam spill. In an astroparticle
experiment an event record may correspond to data collected starting from a trigger
signal for a certain length of time. Furthermore, due to performance requirements
of data acquisition systems, raw data is often compressed, encoded or packed into
rather complex data structures, which are often not very convenient for direct use in
reconstruction programs. Therefore, a raw event record is usually read from disk and
immediately “unpacked” into simpler but larger data structures where the digitized
signals are represented by standard integer or floating point numbers.
The output of the most complete simulations (often called “full” simulations,
see below) can be stored in “packed raw” format identical to the detector data, or
in “unpacked raw” format in which case the unpacking step is omitted in reading
simulated event records. 57 Thereafter, simulated event records are treated identically
to detector “real” data.
A number of event records are written by the data acquisition system to a raw
data file, which is the main data item delivered from the “online” to the “offline”
environment. The organization of event records into raw data files is very often
unrelated to the experimental conditions and simply reflects technical constraints
such as the size of disk buffers in the online and offline clusters.
55 The names of these tasks are not standardized. Therefore readers will have to identify the
corresponding task names for their respective project.
56 In electron-positron collisions there is a single collision most of the time, but there may be
occasionally an annihilation event together with a two-photon collision, for example. In proton–
proton collisions there are on average 20 collisions per beam crossing at the nominal luminosity of
the original LHC configuration.
57 Even though it would be more economical to store simulated data in “packed raw” format, this is
often not possible. For example, the simulations may be needed before the detector data acquisition
system is fully designed and implemented, and therefore the exact format for packed raw data will
not be known.