\documentclass[11pt]{article}
\usepackage{a4}
\usepackage{graphicx}

\oddsidemargin=0pt           % No extra space wasted after first inch.
\evensidemargin=0pt          % Ditto (for two-sided output).
\topmargin=0pt               % Same for top of page.
\headheight=0pt              % Don't waste any space on unused headers.
\headsep=0pt
\textwidth=16cm              % Effectively controls the right margin.
\textheight=24cm

\begin{document}
\title{\bf CALICE ECAL Readout Electronics: Data Acquisition Requirements}

\maketitle

\section{Introduction}
The readout electronics must interface to a data acquisition system
and allow the ECAL channels to be read out. In principle, zero
suppression could be done in hardware, although there must be some
ability to read out the raw values for pedestal and noise calculations.
The proposed system reads out all raw data for every event.

The system must also be flexible to allow for the uncertainties of
the HCAL, trigger and beam monitoring readout, none of which are
well-defined at this stage.

\section{Event numbers}
The main aim of the project is to get precise data on hadronic interactions
to compare with simulation. The precision achievable obviously
depends on the number of events taken. If it is assumed that a 5\% accuracy
is needed for a $3\sigma$ tail (0.13\% of the total) of a distribution,
then 400 events are needed in this region. This corresponds to a total
of $3 \times 10^5$ events.

This number of events is needed for each of several experimental
configurations. The quantities varying between the setups are:
\begin{itemize}
\item The particle type; at least electrons and pions will be needed,
and possibly muons also. Assume 2 variations.
\item The beam energy; energies between 1 and 10 GeV are needed,
ideally data with 3 or 4 different energies would be taken.
Assume 4 variations.
\item The HCAL; data with both the tile and two digital HCAL options
are needed. Assume 3 variations.
\item Entrance angle; normal and $45^\circ$ incidence angles
are wanted. Assume 4 variations.
\item Preshower; material will be included in front of the ECAL
for some data. Assume 2 variations.
\end{itemize}
Although not all combinations are particularly meaningful, the simple
calculation of doing all would give a total of
$2 \times 4 \times 3 \times 4 \times 2 = 192$ variations.
This would
imply a total data sample of around $6 \times 10^7$ events.

\section{Event rates}
Most beam lines operate with the particles arriving in bunches, typically
with roughly a 10\% duty factor. A sustained rate of around 100Hz is
required, so that the peak rate achievable within a bunch should be
around 1kHz.

At this rate, the time to acquire the 300k
events needed for each experimental configuration is 3000 s, or
around 1 hour. Even allowing for significant setup time for
each configuration, it seems feasible to complete the beam test
within a couple of months.


\section{Data rates and volumes}
The ECAL data will be around 19 kBytes per event. The tile HCAL
option has up to 1500 channels, each reading 16 bits, and so
corresponds to around 3 kBytes. Both the digital HCAL options will have
10k channels in each of up to 38 layers, with each channel
corresponding to one bit. This gives a total of around $4 \times 10^5$
bits or 50 kBytes without any zero suppression.
With the expected suppression, around 2 kBytes per event on average
are expected at the highest energies.
Some beam monitoring and trigger data need to be included also,
which should be 1 kByte or less.

Assuming the event sizes are around 25 kBytes, then the realistic
VME backplane speed of around 20 MBytes/s will limit the event rate
to around 800 Hz maximum, which is close to, but not quite at, the
1 kHz requirement.

With an average data size of 25 kBytes per event, then the total
data sample of $6 \times 10^7$ events will be 1.5 TBytes.
Calibration and cosmics runs are assumed to be comparatively small
and have not been included in this estimate.

To avoid problems with large file sizes ($> 2$ GBytes for standard Linux),
then the number of events per file (assumed to be a run) would
need to be restricted to around 80k events, which would imply a run
would last around 800s or 13 minutes. A single configuration sample would
be four runs and the total sample would be around 800 runs.

\end{document}
