14 Distributed Computing
629
small, as is the size of the output file (which is often called a “four-vector file”). 61
A single (non-parallel) job can usually produce enough four-vectors for a whole
simulation campaign. The situation is completely different in the next step, where
the four-vectors go through a full detector simulation which is very CPU time
consuming. Many jobs must be run in parallel reading four-vectors and writing
simulated event records 62 to Disk servers. The data rate per job is not very high,
but the integrated output rate can be substantial since there are many CPU servers
running simultaneously, an issue that should be taken into account. Simulation is
often run on many separate clusters and the oversight of simulation productions
can consume substantial amounts of time from a large number of physicists.
Deployment of Grid interfaces on clusters (see below) has simplified these tasks
somewhat. A recent tendency is to use “production management systems” based
on databases to keep track of simulation jobs. The most tedious part, however, is
the detection and correction of errors coming from the execution of the simulation
program itself, which currently is not automated in part due to lack of a systematic
approach to error signaling.
14.4.3 Data Reduction and Event Filtering
Appropriate data representations for physics analysis are quite different from the
raw data format. They can also be quite different from the reconstruction output
format for several reasons, some related to enabling limited reprocessing capabilities
from the reconstruction output itself, while others are related to signal-to-noise
issues. Reconstruction output may have a format optimized for limited reprocessing
without access to the raw data, for example recalculating vertices from tracks or
track and calorimeter cluster matches. This format may not be optimal for analysis.
A simple example can illustrate this: a typical analysis condition is to access
all tracks that have a given minimum number of points (or “hits”); hence, the
optimum data structure is a list of tracks, each track having the property “number
of points”. The reconstruction output, however, will most likely be stored as a list
of points, each point having a property of belonging to a track, a data structure
optimized for reprocessing the assignment of points to tracks, but completely
“backwards” from the one needed for optimal analysis. Reconstruction output will
often have additional information stored, related to enabling reprocessing, which
makes it too bulky for practical use in analysis. It is often organized keeping a
61 A single generation step is described for simplicity. Note that in some cases the output of an event
generator may need to be post-processed by another physics simulation program, for example to
turn quarks and gluons into jets.
62 A single step is described for simplicity. Note that in some cases the output of the detector
simulation may have to be post-processed to generate simulated event records, for example by
adding simulated pile-up events for proton–proton collisions in the LHC.
629
small, as is the size of the output file (which is often called a “four-vector file”). 61
A single (non-parallel) job can usually produce enough four-vectors for a whole
simulation campaign. The situation is completely different in the next step, where
the four-vectors go through a full detector simulation which is very CPU time
consuming. Many jobs must be run in parallel reading four-vectors and writing
simulated event records 62 to Disk servers. The data rate per job is not very high,
but the integrated output rate can be substantial since there are many CPU servers
running simultaneously, an issue that should be taken into account. Simulation is
often run on many separate clusters and the oversight of simulation productions
can consume substantial amounts of time from a large number of physicists.
Deployment of Grid interfaces on clusters (see below) has simplified these tasks
somewhat. A recent tendency is to use “production management systems” based
on databases to keep track of simulation jobs. The most tedious part, however, is
the detection and correction of errors coming from the execution of the simulation
program itself, which currently is not automated in part due to lack of a systematic
approach to error signaling.
14.4.3 Data Reduction and Event Filtering
Appropriate data representations for physics analysis are quite different from the
raw data format. They can also be quite different from the reconstruction output
format for several reasons, some related to enabling limited reprocessing capabilities
from the reconstruction output itself, while others are related to signal-to-noise
issues. Reconstruction output may have a format optimized for limited reprocessing
without access to the raw data, for example recalculating vertices from tracks or
track and calorimeter cluster matches. This format may not be optimal for analysis.
A simple example can illustrate this: a typical analysis condition is to access
all tracks that have a given minimum number of points (or “hits”); hence, the
optimum data structure is a list of tracks, each track having the property “number
of points”. The reconstruction output, however, will most likely be stored as a list
of points, each point having a property of belonging to a track, a data structure
optimized for reprocessing the assignment of points to tracks, but completely
“backwards” from the one needed for optimal analysis. Reconstruction output will
often have additional information stored, related to enabling reprocessing, which
makes it too bulky for practical use in analysis. It is often organized keeping a
61 A single generation step is described for simplicity. Note that in some cases the output of an event
generator may need to be post-processed by another physics simulation program, for example to
turn quarks and gluons into jets.
62 A single step is described for simplicity. Note that in some cases the output of the detector
simulation may have to be post-processed to generate simulated event records, for example by
adding simulated pile-up events for proton–proton collisions in the LHC.