\chapter{Simulation}
%Andreas Morsch the editor of this chapter.
%andreas.morsch@cern,ch
\label{CH:Simulation}

\section{Event generators}
\label{SEC:Event_generators}

Heavy-ion collisions produce a very large number of particles in the
final state. This is a challenge for the reconstruction and analysis
algorithms which require a predictive and precise simulation of the
detector response.

The ALICE experiment was designed when the highest nucleon--nucleon
center-of-mass energy in heavy-ion interactions was at 20~GeV
per nucleon--nucleon pair at the CERN SPS, i.e.\ a factor of about 300
less than the LHC energy.  Model predictions, discussed in Volume 1 of
the the ALICE Physics Performance Report~\cite{CH4Ref:PPRV1}, for the
particle multiplicity in \mbox{Pb--Pb} collisions at LHC vary from
1400 to 8000 charged particles per rapidity unit at mid-rapidity.  In
summer 2000 the RHIC collider came online.  The RHIC data seem to
suggest that the LHC multiplicity will be on the lower side of the
predictions.  However, the RHIC top energy of $200\, {\rm GeV}$ per
nucleon--nucleon pair is still 30 times less than the LHC energy.  The
extrapolation is so large that both the hardware and software of ALICE
had to be designed to cope with the highest predicted multiplicity.
On the other hand, we have to use different generators for the primary
interaction, since their predictions are quite different at LHC
energies.  

The simulations of physical processes are confronted with
several issues:

\begin {itemize}
%\parskip=0.pt \parsep=0.pt 
\itemsep=1.5pt
\item Existing event generators give different predictions for the
expected particle multiplicity, \pt\ and rapidity distributions, and
the dependence of different observables on \pt\ and rapidity at LHC
energies.

\item Most of the physics signals, like hyperon production, high-\pt\
observables, open charm and beauty, quarkonia, etc.\ even at lower
energies, are not exactly reproduced by the existing event generators.

\item Simulation of small cross-section observables would demand
prohibitively long runs to simulate a number of events that is
commensurable with the expected number of detected events in the
experiment.

\item The existing generators do not simulate correctly some features
like momentum correlations, flow, etc.\
\end {itemize}

Nevertheless, to allow for efficient simulations we have developed the
offline framework such that it allows for a number of options:

\begin{itemize}
\itemsep=1.5pt
\item The simulation framework provides an interface to several 
external generators, like for example HIJING~\cite{CH4Ref:HIJING} 
and DPMJET~\cite{CH4Ref:DPMJET}. 

\item A simple event generator based on parametrized $\eta$ and \pt\
distributions can provide a signal-free event with multiplicity as a
parameter.

\item Rare signals can be generated using the interface to external
generators like PYTHIA~\cite{CH4Ref:PYTH} or simple parametrizations
of transverse momentum and rapidity spectra defined in function
libraries.

\item{} The framework provides a tool to assemble events from
different signal generators (event cocktails).

\item{} The framework provides tools to combine underlying events
and signal events on the primary particle level (cocktail) and on
the digit level (merging).

\item{} Afterburners are used to introduce particle correlations
in a controlled way.
\end{itemize}


\begin{figure}[b!]
\centering
\includegraphics[width=10cm]{chap4fig/aligen.eps}
\caption{{\tt AliGenerator} is the base class that has the
responsibility of generating the primary particles of an event. 
Some realizations of
 this class do not generate the particles themselves but delegate the
 task to an external generator like PYTHIA through the {\tt
 TGenerator}
 interface.  }
\label{CH4Fig:aligen}
\end{figure}

The implementation of these strategies is described below.  The
theoretical uncertainty on the description of heavy-ion collisions at
LHC has several consequences for our simulation strategy.  A large
part of the physics analysis will be the search for rare signals over
an essentially uncorrelated background of emitted particles.  To avoid
being dependent on a specific model, and to gain in efficiency and
flexibility, we generate events from a specially developed
parametrization of a signal-free final state.  This is based on a
parametrization of the HIJING pseudo-rapidity ($\eta$) distribution
and of the transverse momentum (\pt) distribution of
CDF~\cite{CH4Ref:CDF} data.  To simulate the highest anticipated
multiplicities we scale the $\eta$-distribution so that up to 8000
charged particles per event are produced in the range $| \eta | <
0.5$.  Events generated from this parametrization are sufficient for
a large number of studies, such as optimization of detector and
algorithms performance, e.g.\ studies of track reconstruction efficiency as a
function of particle multiplicity and occupancy. For physics performance
studies, we have to simulate more realistic Pb--Pb collisions. 
HIJING, which yields charged particle multiplicities of up to  
${\rm d}N/{\rm d}\eta \approx 6000$, is used to simulate the underlying event that is 
subsequently merged with different signals like jets or heavy flavour. 

In order to facilitate the usage of different generators we have developed a
generator base class called {\tt AliGenerator}, see Fig.~\ref{CH4Fig:aligen}.  
%% Replace this by something closer to the AliGenerator interface
Each {\tt AliGenerator} implementation has to provide a basic set of
configuration methods such as kinematics and vertex cuts. 
A high degree of flexibility is reached by providing several pointers as data 
members to: 
\begin{itemize}
\item {\tt TGenerator} in order to use external generators (see below);
\item {\tt AliVertexGenerator} for the possibility to obtain the event vertex from an external source 
needed for event merging;
\item {\tt AliCollisionGeometry} to provide a collision geometry (impact parameter, number of participants, etc.\ ) to the event header or to other generators;
\item {\tt AliStack} to allow for the stand-alone use of a generator.
\end{itemize}

Several event generators are available via the abstract \ROOT class
that implements the generic generator interface, {\tt TGenerator}.
Through implementations of this abstract base class we wrap FORTRAN
\MC codes like PYTHIA, HIJING, etc.\ that are thus accessible
from the \aliroot classes. In particular, the interface to PYTHIA,
{\tt AliPythia} deriving from {\tt TPythia}, 
includes the use of nuclear structure functions of PDFLIB and a large set 
of preconfigured processes such as jet-production, heavy flavours, and pp
minimum bias.

In many cases, the expected transverse momentum and rapidity
distributions of particles are known. In other cases the effect of
variations in these distributions must be investigated. In both
situations it is appropriate to use generators that produce primary
particles and their decays sampling from parametrized spectra. To meet
the different physics requirements in a modular way, the
parametrizations are stored in independent function libraries wrapped
into classes that can be plugged into the generator. This is
schematically illustrated in Fig.~\ref{CH4Fig:evglib} where four
different generator libraries can be loaded via the abstract generator
interface.

It is customary in heavy-ion event generation to superimpose different
signals on an event to tune the reconstruction algorithms. This is
possible in \aliroot via the so-called cocktail generator
(Fig.~\ref{CH4Fig:cocktail}).  This creates events from user-defined
particle cocktails by choosing as ingredients a list of particle
generators.

\begin{figure}[ht]
\centering
\includegraphics[width=10cm]{chap4fig/evglib.eps}
\caption{{\tt AliGenParam} is a realization of {\tt AliGenerator}
that generates particles using parametrized $\pt$ and
pseudo rapidity distributions. Instead of coding a fixed number of
parametrizations directly into the class implementations, user-defined 
parametrization libraries (AliGenLib) can be connected at
run time allowing for maximum flexibility.} 
\label{CH4Fig:evglib}
\end{figure}

\begin{figure}[ht]
\centering
\includegraphics[width=10cm]{chap4fig/cocktail.eps}
\caption{The {\tt AliCocktail} generator is a realization of {\tt
AliGenerator} which does not generate particles itself but
delegates this task to a list of objects of type {\tt
AliGenerator} that can be connected as entries ({\tt
AliGenCocktailEntry}) at run time. In this way different physics
channels can be combined in one event.} 
\label{CH4Fig:cocktail}
\end{figure}


\section{Afterburner processors and correlation analysis}
\label{SEC:afterburn}

The modularity of the event generator framework allows easy
integration with the simulation steering class {\tt AliRun} and with
the objects that are responsible for changing the output of event
generators or for assembling new events making use of the input of
several events. These processors are generally called
`afterburners'. They are especially needed to introduce a controlled
(parametrized) particle correlation into an otherwise uncorrelated
particle sample. In \aliroot this task is further simplified by the
implementation of a stack class ({\tt AliStack}) that can be connected
to both {\tt AliRun} and {\tt AliGenerator}.  Currently, afterburners
are used for the simulation of the two-particle correlations,
flow signals, and jet quenching.

\vspace{-0.2cm}
\section{Detector response simulation}
\label{SEC:Detector_response_simulation}

To respond to the ALICE simulation requirements, it is important to
have a high-quality and reliable detector response simulation code.
One of the most common programs for full detector simulation is
\gthree~\cite{CH4Ref:G3} which, however, is a 20-year old FORTRAN
program, not being (officially) further developed since 1993.
\gfour~\cite{CH4Ref:G4} is being developed by a large
international collaboration with a strong component in CERN/IT as the
OO simulation package for the LHC.  We are also using
FLUKA~\cite{CH4Ref:FLUKA} as a full detector simulation
program. These three programs have a very different user interface, 
therefore we decided to build an environment that could take
advantage of the maturity and solidity of \gthree and, at the same
time, protect the investment in the user code when moving to a new
\MC. In order to combine immediate needs and long term
requirements into a single framework, we wrapped the \gthree code in a
C++ class ({\tt TGeant3}) and we developed a Virtual \MC (VMC)
abstract interface (now part of \ROOT, see below).  We have interfaced
\gfour and FLUKA with our virtual \MC interface.  We will thus
be able to change the simulation engine without any modification in
the user detector description and signal generation code.  This
strategy has proved very satisfactory and we are able to assure
coherence of the whole simulation process which includes the following
steps regardless of the particle transport package in use:

\vspace{-0.2cm}
\begin{itemize}
\parskip=0.pt \parsep=0.pt \itemsep=5.0pt
\item {\bf Event generation of final-state particles:} The collision
  is simulated by a physics generator code or a parametrization and
  the final-state particles are fed to the transport program.
\item {\bf Particle transport:} The particles emerging from the
interaction of the beam particles are transported in the material of
the detector, simulating their interaction with it and the energy
deposition that generates the detector response (hits). An 
event display is shown in Colour Figure II.
\item {\bf Signal generation and detector response:} During this phase
the detector response is generated from the energy deposition of the
particles traversing it. This is the ideal detector response, before
the conversion to digital signals and the formatting of the front-end
electronics is applied.
\item {\bf Digitization:} The detector response is digitized and
formatted according to the output of the front-end electronics and the
data acquisition system. The results resemble closely the real
data that will be produced by the detector.
\item {\bf Fast simulation:} The detector response is simulated via
  appropriate parametrizations or other techniques that do not
  require the full particle transport.
\end{itemize}

\vspace{-0.3cm}
\section*{Virtual \MC interface}
\label{SEC:Virtual_Monte_Carlo_interface}

\vspace{-0.1cm}
As explained above, our strategy to isolate the user code from changes
of the detector simulation package was to develop a virtual interface
to the detector transport code. We call this interface Virtual \MC.
It is implemented~\cite{CH4Ref:VirtMC} via C++ virtual classes
and is schematically shown in Figs.~\ref{CH4Fig:vmc}
and.~\ref{CH4Fig:vmc_alice}. The codes that implement the abstract
classes are real C++ programs or wrapper classes that interface to
FORTRAN programs.

An additional step is to replace the geometrical modeller of the
different packages with a single one, independent from any specific
simulation engine; the aim is to use the same geometrical modeller also
for reconstruction and analysis.  Thanks to the collaboration between
the ALICE Computing project and the \ROOT team, we have developed a
geometrical modeller, {\tt TGeo} \cite{CH4Ref:TGEO}, that is able to represent the ALICE
detector, and to replace the \gthree modeller for navigation in the
detector.  It has also been interfaced to FLUKA and discussions are
under way with the \gfour team to interface it to the \gfour \MC.
Using the {\tt roottog4} converter, geometries defined for {\tt
TGeo} can be converted into \gfour geometries.

\begin{figure}[t!]
\centering
\includegraphics[width=15cm]{chap4fig/vmc_1.eps}
\caption{The Virtual \MC concept.} 
\label{CH4Fig:vmc}
\end{figure}

\begin{figure}[t!]
\centering
\includegraphics[width=14cm]{chap4fig/vmc_2.eps}
\caption{The Virtual \MC design and its realization within the \aliroot framework.} 
\label{CH4Fig:vmc_alice}
\end{figure}

Using the virtual \MC we have converted all FORTRAN
user code developed for \gthree into C++, including the geometry
definition and the user scoring routines, {\tt StepManager}. These
have been integrated in the detector classes of the \aliroot
framework. The output of the simulation is saved directly with
\ROOT I/O, simplifying the development of the digitization and
reconstruction code in C++.


\subsection*{GEANT}
\gthree is the detector simulation \MC code used extensively so
far by the HEP community for simulation of the detector response.
However, it is no longer maintained and has several known drawbacks,
both in the description of physics processes, particularly
hadronic~\cite{CH4Ref:atlaspap}, and of the geometry.  
Its designated successor is \gfour.
ALICE has spent
considerable effort in evaluating \gfour via several benchmarks;
details on ALICE experience with \gfour can be found in
Ref.~\cite{CH4Ref:ALICEG4}. We were able to keep the same geometry
definition using the {\tt G3toG4} utility to translate from \gthree to
\gfour geometry; in addition we have improved {\tt G3toG4} and made it
fully operational.  The virtual \MC interface allows us to run
full ALICE simulations also with \gfour and to compare them with the \gthree
results; the advantage being that both simulation programs use the
same geometry and the same scoring routines.  An additional advantage
is a substantial economy of effort.  Using the same geometry
description eliminates one of the major sources of uncertainty and
errors in the comparison between different Monte Carlos, which comes
from the fact that it is rather difficult to make sure that, when
comparing two Monte Carlos on a particular experimental configuration,
there are no differences in the geometry description and in the
scoring. 

This exercise has exposed the \gfour code to a real
production environment and we experienced several of its weaknesses.
We faced several problems with its functionality that have required
substantial user development. In particular, the definition of volume
or material-specific energy thresholds and mechanism lists are not
so straightforward as in \gthree.  
The strategy of \gthree was to provide the user one state-of-the-art implementation of 
the physics processes together with a few configuration options essentially for performance optimization
and debugging. 
In contrast, \gfour has to be configured using so-called physics lists corresponding 
to different combinations of model implementation that in addition may 
vary from detector to detector. They need a great amount of inside knowledge to be used correctly.  

We have also performed a
number of benchmark tests of the hadronic~\cite{CH4Ref:isidro} and
low-energy neutron transport~\cite{CH4Ref:tiara}.

We are now planning to interface \gfour with the \ROOT geometrical
modeller to avoid the conversion step via {\tt G3toG4} and to take
advantage from its advanced solid modelling capabilities.


\subsection*{FLUKA}

FLUKA plays a very important role in ALICE for all the tasks where
detailed and reliable physics simulation is vital, given its thorough
physics validation and its almost unique capability to couple
low-energy neutron transport with particle transport in a single
program. These include background calculation, neutron fluence, dose
rates, and beam-loss scenarios~\cite{CH4Ref:FLUMAmod}.
An example for a neutron fluence map obtained with FLUKA is shown in 
Colour Figure III.
FLUKA has been particularly important for ALICE in the design of the front absorber
and beam shield. To ease the input of the FLUKA geometry, ALICE has
developed an interactive interface~\cite{CH4Ref:alife}, called {\tt
ALIFE}, that allows setups described with FLUKA to be combined and
modified easily.  Figure~\ref{CH4Fig:alife} schematically describes
the use of {\tt ALIFE} to prepare the input for FLUKA.

To provide another alternative to \gthree for full detector simulation,
we have developed an interface with FLUKA, again via the Virtual \MC.
The native FLUKA geometry modeller has been replaced by {\tt
TGeo} which allows us to run FLUKA with the same geometry as used for
\gthree and \gfour simulations.

Rigorous tests have been performed to ensure that the FLUKA native geometry modeller 
and navigator and the FLUKA interfaces to {\tt TGeo} give exactly the same results.
Based on these tests, the FLUKA Project considers the FLUKA-{\tt TGeo} as validated.

\begin{figure}[t!]
\centering
\includegraphics[width=9.2cm]{chap4fig/alife.eps}
\caption{Example of the use of ALIFE. The ALIFE editor allows easy
  creation of an ALIFE script, which is in fact FLUKA input
  geometry. FLUKA is then used to transport particles, including
  low-energy neutrons, to a virtual boundary surface. The particles are
  then written to a file that is used as a source for a regular
  \aliroot simulation to evaluate the detector response to background.}
\label{CH4Fig:alife}
\end{figure}


\subsection{Simulation framework}

The \aliroot simulation framework can provide data at different stages
of the simulation process~\cite{CH4Ref:ALICEsim}, as described in
Fig.~\vref{CH2Fig:Parab}.  Most of the terminology comes from
\gthree. First, there are the so-called hits that represent the
precise signal left by the particle in the detector before any kind of
instrumental effect, i.e.\ precise energy deposition and
position. These are then transformed into the signal produced by the
detector, summable digits that correspond to the raw data before
digitization and threshold subtraction.  The introduction of summable
digits is necessary because of the embedding simulation strategy
elaborated for the studies in the Physics Performance Report. These
summable digits are then transformed into digits that contain the same
information as raw data, but in \ROOT structures. The output of raw
data in DATE (the ALICE data acquisition
system~\cite{CH4Ref:DATE}) format has already been done during the
data challenges.

\begin{figure}[ht]
\centering
\includegraphics[width=14.5cm]{chap4fig/alice1s_l1.eps}
\caption{\aliroot simulation of the ALICE detector.}
\label{CH4Fig:alicesim}
\end{figure}

The ALICE detector is described in great detail, see
Fig.~\ref{CH4Fig:alicesim}, including services and support structures,
beam pipe, flanges, and pumps. The \aliroot geometry follows the
evolution of the baseline design of the detector in order to
continuously provide the most reliable simulation of the detector
response. \aliroot is also an active part of this process since it has
been used to optimize the design, providing different geometry options
for each detector. The studies that provided the results presented in
the PPR were performed with the baseline geometry.

\subsection{Geometry of structural elements}

The description of the front- and small-angle absorber regions is very
detailed on account of their importance to the muon spectrometer.  The
simulation has been instrumental in optimising their design and in
saving costs without a negative impact on the physics performance.
The material distribution and magnetic fields of the L3 solenoidal
magnet and of the dipole magnets are also described in detail.  The
magnetic field description also includes the interference between the
two fields.  The field distributions are described by three
independent maps for 0.2, 0.4 and $0.5 \, {\rm T}$ solenoid L3
magnetic field strengths.  Alternatively, it is possible to use simple
parametrizations of the fields, i.e.\ constant solenoidal field in
the barrel and a dipole field varying along the $z$ direction for the muon
spectrometer.  The space frame, supporting the barrel detectors, is
described according to its final design taking into account
modifications to the initial design such that it allows the eventual
addition of a proposed electromagnetic
calorimeter~\cite{CH4Ref:EMCAL}.

The design of the ALICE beam pipe has also been finalized. All
elements that could limit the detector performance (pumps, bellows,
flanges) are represented in the simulation.

\subsection{Geometry of detectors}

Most of the detectors are described by two versions of their geometry;
a detailed one, which is used to accurately simulate the detector
response and study their performance, and a coarse version that
provides the correct material budget with minimal details, and is used
to study the effect of this material budget on other detectors.  For
some detectors, different versions of the geometry description
corresponding to different geometry options are selectable via the
input C++ script at run time. In the following we give some examples.
We remind the reader that some of this information is still subject to
rapid evolution.

Both a detailed and a coarse geometry are available for the ITS.  The
detailed geometry of the ITS is very complicated (see Colour Figure IV)
and crucially affects the evaluation of impact parameter and electron bremsstrahlung. On the
other hand, simulation of the coarse geometry is much faster when ITS
hits are not needed.

Three configurations are available for the TPC. Version 0 is the
coarse geometry, without any sensitive element specified. It is used
for the material budget studies and is the version of interest for the
outer detectors. Version 1 is the geometry version for the Fast
Simulator. The sensitive volumes are thin gaseous strips placed in the
Small (S) and Large (L) sectors at the pad-row centres.  The hits are
produced whenever a track crosses the sensitive volume (pad-row). The
energy loss is not taken into account. Version 2 is the geometry
version for the slow simulator. The sensitive volumes are S and L
sectors.  One can specify as sensitive volumes either all sectors or
only a few of them, up to 6 S and 12 L sectors. The hits are produced
in every ionizing collision.  The transport step is calculated for
every collision from an exponential distribution. The energy loss is
calculated from an $1/E^2$ distribution and the response is
parametrized by a Mathieson distribution.

The TRD geometry is simulated in great detail, including the correct
material budget for electronics and cooling pipes. The full response
and digitization have been implemented allowing studies of open
questions such as the number of time-bins, the 9- or 10-bit ADC, the
gas and electronics gain, the drift velocity, and maximum Lorentz
angle. The transition-radiation photon yield is approximated by an
analytical solution for a foil stack, with adjustment of the yield for
a real radiator, including foam and fibre layers from test beam
data. This is quite a challenging detector to simulate, as both normal
energy loss in the gas and absorption of transition-radiation photons
have to be taken into account.  During the signal generation several
effects are taken into account: diffusion, 1-dimensional pad response,
gas gain and gain fluctuations, electronics gain and noise, as well as
conversion to ADC values. Absorption and ${\bf E}\times {\bf B}$
effects will be introduced.

A detailed study of the background coming from slow neutron capture in
Xe gas was performed~\cite{CH4Ref:Georgios} with FLUKA. The spectra of
photons emitted after neutron capture are not included in standard
neutron-reaction databases. An extensive literature search was
necessary in order to simulate them. The resulting code is now part of
the FLUKA \MC~\cite{CH4Ref:Xenon}.

The TOF detector covers a cylindrical surface of polar acceptance
$|\theta-90 ^{\circ}|< 45^{\circ}$. 
It has a modular structure corresponding to 18 sectors in $\varphi$
and to 5 segments in $z$.  All modules have the same width of 128~cm
and increasing lengths, adding up to an overall TOF barrel length of
750~cm.  Inside each module the strips are tilted, thus minimizing the
number of multiple partial-cell hits due to the obliqueness of the
incidence angle.  The double stack-strip arrangement, the cooling
tubes, and the material for electronics have been described in
detail. During the development of the TOF design several different
geometry options were studied, all highly detailed.

The HMPID detector also poses a challenge in the simulation of the
Cherenkov effect and the secondary emission of feedback photons. A
detailed simulation has been introduced for all these effects and has
been validated both by test-beam data and with the ALICE RICH
prototype that has been operating in the STAR experiment.
An event display with the typical rings is shown in Colour Figure V.

The PHOS has also been simulated in detail.  The geometry includes the
Charged Particle Veto (CPV), crystals (EMC), readout (APD) and
support structures. Hits record the energy deposition in one CPV and
one EMC cell per entering particle. In the digits the contribution
from all particles per event are summed up and noise is added.

The simulation of the ZDC in \aliroot  requires transport of spectator
nucleons with Fermi spread, beam divergence, and crossing angle for
over 100~m. The HIJING generator is used for these studies taking into
account the correlations with transverse energy and multiplicity.
Colour Figure VI shows the result of the simulation of the hadronic shower induced
by a 2.7 TeV neutron.

The muon spectrometer is composed of five tracking stations and two
trigger stations for which  
detailed geometries have been implemented. Supporting frames and
support structures are coarsely described but they are not very
important in the simulation of the signal. The muon chambers have a
complicated segmentation that has been implemented during the signal
generation via a set of virtual classes. This allows one to change the
segmentation without modifying the geometry.

Summable digits (pad hits) are generated taking into account the
Mathieson formalism for charge distribution, while work is ongoing on
the angular dependence, Lorentz angles and charge correlation.

The complex T0--FMD--V0--PMD forward detector system is still under
optimization. Several options are provided to study their performance.

The description of ALICE geometry and the generation of simulated data
are in place.  Hence the offline framework allows the full event
reconstruction including the main tracking devices.  The framework
also allows comparison with test-beam data.  The early availability of
a complete simulation has been an important point for the development
of reconstruction and analysis code and user interfaces, which is now
the focus of the development.

\section{Fast simulation}
\label{SEC:Fast_simulation}

Owing to the expected high particle multiplicity for heavy-ion
collisions at the LHC, typical detector performance studies can be
performed with a few thousand events. However, many types of physics
analysis, in particular of low cross-section observables, such as D
meson reconstruction from hadronic decay channels, have to make use of
millions of events.  Computing resources are in general not available
for such high-statistics simulations.

To reach the required sample size, fast simulation methods based on
meaningful parametrizations of the results from detailed and
consequently slow simulations are applied. The systematic error
introduced by the parametrizations is in general small compared with
the reduction of the statistical error. This is particularly true for
the studies of the invariant-mass continuum below a resonance
(cocktail plots).

It is hard to find a common denominator for fast simulation methods
since they are very specific to the analysis task. As a minimum
abstraction, we have designed base classes that allow for a
representation of the detector or detector systems as a set of
parametrizations of acceptance, efficiency, and resolution. The Muon
Spectrometer fast simulation has been implemented using these classes.

Another interesting development concerns the fast simulation of the
resolution and efficiency of track reconstruction in the central barrel.  In this
approach, resolution and efficiency in TPC are obtained from the track
parameters at the inner radius of the TPC, using a
parametrization. After this, full track reconstruction is performed for the inner
tracking system, which is needed for detailed secondary vertex
reconstruction studies.  For details see Ref.~\cite{CH4Ref:DAINESE}.

\section{Event merging and embedding}
\label{SEC:Event Merging}
The simulation of small cross-section observables would demand
prohibitively long runs to simulate a number of events
commensurable with the expected number of detected events in the
experiment. 
To circumvent this problem we use an event merging procedure:
during digitization we produce so called summable digits. These are digits before the 
addition of electronic noise and pedestal subtraction. Merged events are produced by adding 
the summable digits from background and signal events. Each background event is used 
$n$ times for merging. 
Since computing time is dominated by the simulation of the background events, 
in this way the event statistics is increased by a factor of $n$.

A similar technique called embedding consists in mixing data from simulation with real events.  
This allows for the realistic evaluation of track reconstruction performance in a high-particle-density environment.
Here, events are mixed on the level of ADCs and are subsequently passed to the standard reconstruction code.