\documentclass{CHEP2006}
\setlength{\paperheight}{297mm}
\setlength{\paperwidth}{210mm}

%%
%%  Use \documentclass[boxit]{JAC2003}
%%  to draw a frame with the correct margins on the output.
%%
%%  Use \documentclass[acus]{JAC2003}
%%  for US letter paper layout
%%

\usepackage{graphicx}

%%
%%   VARIABLE HEIGHT FOR THE TITLE BOX (default 35mm)
%%

\setlength{\titleblockheight}{55mm}

\begin{document}
\title{{\sc Geant4} Muon Digitization in the ATHENA Framework
%\thanks{Revised by , January 12, 2006}
}

\author{D.~Rebuzzi \thanks{daniela.rebuzzi@pv.infn.it}, Universit\`a di Pavia and INFN, Sezione
di Pavia, I-27100, Pavia, ITALY,\\
K.~A.~Assamagan, Brookhaven National Laboratory (BNL) 
                  Department of Physics, Upton , NY, USA,\\
N. Ch. Benekos, MPI fur Physik, Munich, GERMANY,\\
A.~Di Simone, CERN PH-ATC and INFN-CNAF, SWITZERLAND,\\
Y.~Hasegawa, Department of Physics, Shinshu University,  Nagano, JAPAN,\\
N.~Van Eldik, National Institute for Nuclear Physics and High Energy Physics (NIKHEF)\\
Amsterdam, THE NETHERLANDS}

\maketitle

\begin{abstract}
  The aim of this note is to describe the Muon Digitization software packages,
 completely re-written to run in the {\sc Athena} framework and to interface
 with the {\sc Geant4} Muon Spectrometer simulation.

The Muon Digitization is the simulation of the Raw Data Objects (RDO), or
the electronic output, of the Muon Spectrometer. In the present architecture, it consists of two steps:
in the first step, the output
of the detector simulation, the Muon Hits, is converted
to Muon Digits, i.e., intermediate objects that can be fed into the
reconstruction. In the second step, the Muon Digits are converted into RDO,
the transient representation of raw the data byte stream.

In this paper we will describe the detailed implementation of the first step
of the Muon
Digitization, where the detector simulation output is ``digitized'' into Muon
Digits, also referred as Reconstruction Input Objects (RIO). This procedure 
occurs separately for each Muon technology. The second step, 
which convert the RIO in the RDO (byte stream) is implemented in separate algorithms 
and documented in \cite{cnv}.
We will describe the fundamentals of the Muon Digitization algorithms,
outlining the global structure of them, with some emphasis on
the simulation of piled-up events, on the link to the Monte Carlo Truth and on the Digitization 
validation against the Monte Carlo information.


\end{abstract}

\section{Muon Digitization}

The Muon Digitization software has been recently re-written to run
in the {\sc Athena} framework and to operate on the {\sc Geant4} Hits. 
The goal of the Muon Digitization is to simulate the output signal of the ATLAS Muon Detector,
starting from the output of {\sc Geant4} detector simulation.

The new Muon Digitization consists of four algorithms in the {\sc
Athena} sense, one for each muon technology (MDT, RPC, CSC and TGC).
It provides the production of collections of 
simulated Muon Digits out of Muon Hit collections from the {\sc Geant4}
simulation. 

The Muon Digitization has been designed to be independent from the {\sc Geant4} simulation.  
It relies only on the read-out geometry (provided by MuonGeoModel \cite{mgm}) 
and on the detector-specific Muon Spectrometer Offline Identifier (OID) scheme \cite{identifiers}. 


\subsection{Muon Hits}

Hit production in {\sc Geant4} is provided by the {\em Sensitive Detectors\/} classes.
Each time a particle trajectory crosses a volume which can generate hits, the 
kernel is responsible for calling the corresponding Sensitive Detector, which 
implements the hit generation algorithms. Hence, the Sensitive Detector 
generates a list of hits, which are stored as output of the simulation procedure.

Hits have a very light content. They consist of a {\em Simulation Identifier\/} (SimID), 
a 32-bit integer in which the geometry information about the hit position is stored, plus the 
quantity to be digitized. Hits are collected 
using AthenaHitsVector containers, one for each Muon technology, where they are inserted 
in a random way (no sorting is performed at the simulation level). There are therefore
four independent hit collections in the Muon Spectrometer per event, one for each 
technology.

\subsection{Muon Digits}

Muon Digits are the output of the first step of the digitization procedure. They
resemble the detector output and are basically defined by the reconstruction
group. In fact, the Muon Digits 
can be fed directly in 
the Muon Reconstruction, for this they are also referred as Reconstruction Input Objects 
(RIO). They are labeled by an OID which packs the geometry information.
The additional geometry description of the detector elements are obtained from the
MuonGeoModel {\em read-out\/} geometry(\cite{mgm}).

\subsection{Infrastructure for Event Pile-Up}
 
In addition of handling hits coming from a single bunch crossing, 
the digitization is also be able to handle  
{\em piled-up\/} collisions. Before performing the digitization, hits from several 
bunch crossings can be overlaid taking into account the global time of the hit, 
which is defined as the {\sc Geant4} hit time plus the bunch crossing time with 
respect to the main crossing. 
Therefore, simulated {\sc Geant4} hits can be read in together with previously generated 
minimum bias and cavern background events. The hit overlay and sorting according to the
detector elements is then carried out and the digitization proceeds afterwards. 
  
\subsection{Association to Monte Carlo Truth}

Any reference to the Monte Carlo information is lost after the digitization procedure, 
that is, the Muon Digits or the RDO do not carry any link 
(pointer, associations) to the original simulated particles. 
Such ``links'' are necessary to establish the Monte Carlo truth tracks and 
for validation purposes. 

During the Muon Digitization, a separate
object is recorded and can be persistified, to maintain the link to the
original simulated particles at the digit or RDO level. The recorded object in question 
is a map of muon off-line identifiers to MuonSimData objects.
The objects of type MuonSimData are not applicable to the real production running. 
However, they can be made persistent in the simulation of non pile-up 
situations and are useful to carry the associations to the original particles to the tracking 
stage. 

\subsection{Digit Validation}

The XXXDigitValidation algorithms have been implemented in order to check
the correctness of the digit production and of the digitization processes. 
The general method consists of comparing known (``true'') track position with
associated digit position (from MuonGeoModel) and to study the residual
distributions. The Truth information is coming from the MuonSimData (as
discussed in the previous paragraph, a separate
object which can be stored together with the RawData, which maintains the link
to the hits at the Digit/RDO level. The
validation is performed generating single muon events in the barrel,
with no physics processes activated but transportation. 
The output of each validation algorithm is a Ntuple which contains the main
Digit/Truth parameters. The XXXDigitValidation
algorithms are part of the RunTimeTest (RTT) {\sc Athena} nightly control.

Figures from \ref{mdtvalid} to \ref{tgcvalid} show validation plots for each of the four
muon technologies.

\begin{figure}[htb]
\centering
\includegraphics*[width=55mm,angle=-90]{mdtdigival.RTT.eps}
\caption{MDTDigitValidation: pseudorapidity from the digits as a function of the
pseudorapidity of the hits.}
\label{mdtvalid}
\end{figure}

\begin{figure}[htb]
\centering
\includegraphics*[width=65mm,angle=-90]{rpcdigival1.eps}
\caption{ RPCDigitValidation: Scatter plot of $\eta$ and $\phi$
directions of muons not producing any RPC Digit. The inefficiency regions
correspond to Muon Spectrometer areas not instrumented with RPCs.}
\label{rpcvalid}
\end{figure}

\begin{figure}[htb]
\centering
\includegraphics*[width=65mm]{cscavg.eps}
\caption{CSCDigitValidation including the simulation of the electronic ouptut. A 
clusterization is done and the residual is plotted. The residual is determined as the 
local distance from the 
cluster centroid to track in the plane of the wires. Muon tracks, 
originating from a fixed vertex 
(no vertex spreading), normally incident at centrer of the chamber 
(no magnetic field) are considered. The 
residuals from all the chambers are integrated in this plot. It is therefore an 
estimate of the intrinsic 
single hit resolution of the precision strips.}
\label{cscvalid}
\end{figure}

\begin{figure}[htb]
\centering
\includegraphics*[width=75mm]{TGCValidation.eps}
\caption{TGCDigitValidation: Channel number as a function of R postion (left) 
and $\phi$ postion (right). The relation between channel number and R postion is not linear, 
because of number of wire ganged depending on R position. On the other hand, channel postion 
for $\phi$ direction changes linearly with $\phi$ postion}
\label{tgcvalid}
\end{figure}

\section{MDT\_Digitization}

The MDT\_Digitization procedure converts the hit information from the 
{\sc Geant4} simulation into an output which should resembles 
the output signal of the ATLAS detector. Each MDTSimHit contains a SimID, the
impact parameter and the hit position in the global coordinate reference system. 
Each MDT Digit consisting instead of an OID, a TDC count and, optionally, 
a ADC count.

 Starting from the impact parameter, the driftRadius associated to the MDTSimHit, 
 the MDT\_Digitization performs several tasks:
\begin{enumerate}
 \item conversion of the drift radius into a drift time,
 \item calculation of the time structure of the event,
 \item trigger match,
 \item conversion of total time into TDC counts.
\end{enumerate}
  
For the $r \rightarrow t$ conversion, two different {\sc Athena} AlgTools have been 
implemented and 
are available in the MDT\_Digitization package. Due to a modularity of the
architecture, they can be selected via
jobOptions setting the property DigitizationTool of the 
MDT\_Digitizer algorithm. The first is a very detailed
time-consumpting $r \rightarrow t$ procedure (MDT\_Response\_DigiTool) while the second is a 
fast drift distance to time 
conversion which relies on an external rt relation (RT\_Relation\_DigiTool).
More information can be found in
\cite{note}.
 
According to the different contributions to the pulse time, the drift time 
consists of the following components:\\
\begin{equation}
\label{tottime}
t_{tot} = t_{tof} + t_{bunch} + t_{prop} + t_{delay} + t_{drift}
\end{equation}
The time of flight $t_{tof}$ is obtained from the MDTSimHit in form of globalTime. 
The propagation delay $t_{prop}$ is calculated from the position of the hit along the 
tube (obtained from the MuonGeoModel read-out geometry) 
and the signal propagation speed. Additionally, in case of pile-up, 
a bunch crossing offset $t_{bunch}$ is taken into account. 

\begin{figure}[htb]
\centering
\includegraphics*[width=65mm]{dead_time.eps}
\caption{Dead time.}
\label{deadTime}
\end{figure}

\begin{figure}[htb]
\centering
\includegraphics*[width=65mm]{time_window.eps}
\caption{Time windows.}
\label{timeWindow}
\end{figure}
The MDT chambers are equipped with TDCs (Time-to-Digit Converters) 
which measure the signal pulse time for each MDT passing a predefined 
threshold.
To avoid {not physical\/} hit proliferation, the TDCs have a programmable dead 
time which is set to 
the maximum drift time 
of the tube [\cite{MDTASD}] as shown in Figure \ref{deadTime}. The same principle is reproduced 
in the digitization procedure. 

A trigger match criterion is applied to all the selected hits following the same procedure 
(as described in [\cite{timeWindow}]).
First, a trigger time $t_{trig}$ is calculated as follows:\\
\\
$t_{trig} = t_{delay} + t_{ave tof} + t_{bunch offset}$\\
\\
where $t_{delay}$ is the time entering the TDC time calculation \ref{tottime} and $t_{ave tof}$ is
the average time a particle at light speed need to reach the center of the 
chamber (an additional 
offset $t_{bunch offset}$ allows the windows to be positioned with respect
to the {\sc Geant4} global time).
Then, for every hit the time $t_{TDC} - t_{trig}$ is matched with the time windows: 
\begin{Itemize}
 \item if the time of a hit falls within the {\em matching window\/}, a MDT\_Digit is produced;
 \item a hit in the {\em mask window\/} produces a MDT\_Digit which contains no TDC count 
 and is flagged as {\em masked\/};
 \item any hit outside the windows is discarded.
\end{Itemize}
Depending on the sizes of the two windows it is possible to have {\em more that one hit per event 
per tube\/}, both will be stored. 
The TDC count is finally stored into the MDT digit object. 


\section{RPC\_Digitization}

RPC hits are generated by the RPCSensitiveDetector which assigns to them a 
Simulation Identifier (SimID), uniquely identifying the gas gap each hit is 
registered in. The position of the hit in the reference system of the gas gap 
is also stored, together with the time from the beginning of the event, i.e. 
the time of flight of the particle generating the hit.

When a particle generates an avalanche in an RPC, charge signals are 
induced (and detected) on the readout strips. A set of $n$ adjacent strips 
with signals is called a {\em cluster} of size $n$. In RPC operation, due 
to possible signal induction on more than one strip, cluster sizes are in 
general greater than 1, with an average cluster size at working point 
typically of 1.3.
This cluster simulation is done at the digitization level. The RPC\_Digitization 
algorithm reproduces the observed cluster sizes by generating, 
when necessary, digits on strips adjacent to the one actually crossed by the 
particle.
\begin{figure}[htb]
\centering
\includegraphics*[angle=-90,width=75mm]{digiCS3.eps}
\caption{Experimental cluster spread distributions for cluster of sizes 
3 and 4.}
\label{rpcclus1}
\end{figure}

Cluster simulation is carried on in three steps:
\begin{enumerate}
\item experimental distributions are used to decide, according to the impact 
point of the particle along the strip, whether the cluster size will be 1 or 2.
\item experimental distributions are used to decide what the final size of the 
simulated cluster will be.
\item digits are created according to the results of the above steps.
\end{enumerate}
Particular attention is paid to the way the additional digits are 
created around the one actually crossed by the muon. Figure \ref{rpcclus1} 
shows the cluster spread distributions. For each cluster of a given size, the 
plots count which strip was actually crossed by the muon. Upon each bin, the 
corresponding track/strip configuration is showed.


\section{CSC\_Digitization}

The digitization in the CSC is the simulation of the charge 
distribution on the CSC cathode strips given a hit in the sensitive gas. The process also 
identifies the the strips numbers and their orientations. Thus after processing all the hits in 
the event, the CSC digitization outputs the list of digits into the transient event store from 
where they could be picked up by other algorithms. The object referred to as a CSC digit is 
nothing more than the compact identifier of a strip together with the charge on that strip and
the hit time.

\begin{figure}[htb]
\centering
\includegraphics*[width=65mm]{signalShape.eps}
\caption{CSC amplifier signal shape. The signal can be sample at an adjustable rate and a voltage
comparator gives the ADC value at each sampling. The charge on the strip is taken as the difference the 
maximum of positive lobe and the baseline. Finding the maximum and the baseline requires a fit to the ADC
samplings. Then the calibration curve is also needed to convert the maximum to Femto-Coulomb.}
\label{fig:signal}
\end{figure}

The second stage in the digitization is the simulation of the raw data, i.e., the output of the CSC 
electronics. This output consists of a number of ADC values determined by the sampling rate of the 
amplifier signal. The bi-polar shape of the signal, shown in Figure~\ref{fig:signal} is modeled according 
to the following equation:
\begin{equation}
\label{eq:signal_shape}
ADC Value = \left(1.0-\frac{z}{n+1}\right)z^n\exp{(-z)}
\end{equation} 
where $n$ is the number of amplifier integrations, and $z$ is written as follows:
\begin{equation}
\label{eq:z}
z = (samplingTime-startTime) / signalWidth
\end{equation}
and signalWidth is the width of the positive lobe of the bipolar signal. The charge on the 
strip is taken as 
difference between the maximum of the positive lobe and the baseline (pedestal). In the 
simulation, 
the charge on the strip is known, as obtained from the hit digitization: 
the problem therefore consists 
of going from one charge value (in number of equivalent electrons or femtoCoulombs) 
to number $N$ of ADC 
samplings (in ADC counts) at an assumed sampling rate --- 
CSC data will be taken at a variable sampling 
rate. To this end, a conversion of the charge into ADC count is required; then the signal shape 
is 
normalized to the charge (in ADC counts) and sampled to generate the simuated raw data --- 
the ADC samplings 
for each fired strip.

\par
The conversion of the simulated charge on the strip into the ADC counts requires the calibration constants 
for the strip and the calibration curve. An example of a calibration curve for one strip in shown in 
Figure~\ref{fig:calib}. Once the ADC samplings are simulated, they can either to written out in POOL or encoded in the byte stream 
using the format of the ROD.

\begin{figure}[htb]
\centering
\includegraphics*[angle=-90,width=75mm]{cscCalib.eps}
\caption{CSC calibatrion curve for one strips. The calibrations constants are written to and 
obtained form conditions databases.}
\label{fig:calib}
\end{figure}


\section{TGC\_Digitization}

The main functionalities of TGC digitizer are the following:
\begin{itemize}
 \item to create digits from GEANT4 hits,
 \item to simulate detector response (timing, detection efficiency,
       multi signals by a single hit).
\end{itemize}
TGC digitization simulates the following detector responses:
multi hits due to tracks passing several wire gangs or strips
and induced charge spread on cathode plane which may make signals in
several strips,
intrinsic time response due to variation of strength of electric
field in a sensitive layer which depends on injection angle of
charged tracks and signal propagation along wires and strips and 
detection efficiency (sensitivity) of wire gangs and strips.

The multi hits on the strips is made
by the charge spread on the cathode plane which is induced by the
avalanche around anode wires. Multi hits on wire gangs are generated when a charged track passes the
boundary between two wire gangs. In addition, the cross talks between signal channels originating from
readout electronics could be a source of multi hits. At the moment, this
is not taken into account.
Hit positions of R coordinate in TGC
can be read by gangs of wires. Hit positions of $\phi$ coordinate in
TGC can be read by strip. The digitization procedure occurs separately for these two channels.

The intrinsic time response is parametrized using standalone simulations
 and the parametrization had been confirmed by
test beams. Figure~\ref{timejitter} shows that an example of the distribution of time
response of signals from wires. The response time depends on the incident
angle of charged particles. Larger insistent angle gives shorter response
time, this is because the particle can have larger possibility to pass
the stronger electric field in which electrons can reach a wire in short
time.

\begin{figure}[htb]
\centering
\includegraphics*[width=65mm]{timejitter.eps}
\caption{Simulated time response distribution of TGC as a function of
incident angles of charged tracks. Larger angle gives shorter response time.}
\label{timejitter}
\end{figure}

At the moment, the detection efficiency of chambers are averaged over their
sensitive areas. However, the efficiency map of each chamber have
been measured by the test bench with cosmic rays, therefore the use of the
map will be implemented eventually for realistic simulation.


\section{Acknowledgements}
 The authors would like to thank Davide Costanzo for his wise and constant
 supervision and for providing the pile-up infrastructure (together with Paolo
 Calafiura).
 A special thank goes to Alessandro De Salvo for providing the first structure of
 the MDT\_Digitization algorithm which uses the external $rt$ relation. The authors
 are indebted to him and to Ludovico Pontecorvo for providing realistic $rt$
 relations, from Garfield simulation and from data analysis.


\begin{thebibliography}{9}   % Use for  1-9  references
%\begin{thebibliography}{99} % Use for 10-99 references

\bibitem{cnv} K. A. Assamagan {\em et al.\/}, ``{\em Definition of "Raw Data Objects" 
 for the MDT Chambers of the Muon Spectrometer\/}'', ATL-DAQ-2003-022 and
  K. A. Assamagan {\em et al.\/}, ``{\em Raw Data Objects Definition for the RPC 
  chambers of the ATLAS Muon Spectrometer\/}'', ATL-DAQ-2003-018.

\bibitem{mgm} S. Spagnolo {\em et al.\/}, ``{\em The Description of the Atlas Detector\/}'', 
Proceedings of CHEP04, Interlaken, Switzerland, 27 Sep. - 1 Oct. 2004.

\bibitem{identifiers} A.~DiCiaccio {\em et al.\/}, ``{\em Hierarchical Software
Identifier Scheme for the ATLAS\/} {\em Muon Spectrometer\/}'', ATLAS Internal Note,
ATL-MUON-2000-020 (2000).

\bibitem{note} D.~Rebuzzi, K.~A.~Assamagan, A.~Di Simone, Y.~Hasegawa, N.~Van Eldik,, ``{\em 
{\sc Geant4} Muon Digitization in the ATHENA Framework}'', to be submitted at ATLAS-SOFT-COM
note, February 2006.

\bibitem{MDTASD} C.~Posch, E.~Hazen and J.~Oliver, ``{\em CMOS front-end for 
 ATLAS MDT\/}'', ATL-MUON-2002-003, June 2002.
 
\bibitem{timeWindow} Y. Arai, ``{\em AMT-3 (ATLAS Muon TDC version 3) User's 
 manual\/}''.



\end{thebibliography}

\end{document}
