\chapter{Computing~model~and~capacity~requirements} %Yves Schutz the editor of this chapter. \label{CH:Computing_model_and_capacity_requirements} \section{Introduction} This chapter describes the computing model for the processing of the data produced by the ALICE detector in \mbox{pp} and \mbox{A--A} collisions every year. The computing model of the LHC experiements has been already reviewed in 2001 during the so-called LHC Computing Review (LHCCR)~\cite{CH7Ref:LHCCRev}. The model presented in this document however contains several changes with respect to the 2001 version, and it has been reviewed by a subsequent LHCC review that focussed mainly on the requested resources~\cite{CH7Ref:LHCCRev05}. Compared to the 2001 version, the model has been further developed and refined thanks to the experience gained during the Physics Data Challenges. The amount of permanent storage has increased because a duplication of raw data at external Tier~1s is now foreseen in the model. Disk storage has substantially increased: the new estimate is deduced from the disk usage made during the Physics Data Challenges. This document contains also an evaluation of the contributions of Tier~2 centres, which was not present in the ALICE LHCC estimates. \section{Input parameters} \label{CH7:sec:InputParameters} The input parameters for the present computing model are derived from information contained in the ALICE Trigger, DAQ, HLT and Control System TDR~\cite{CH7Ref:trigDaqHltTDR} and the ALICE Physics Performance Report Vol. 1~\cite{CH7Ref:PPR}. All input parameters are to be considered as our best estimates at the moment. They are based on the nominal figures of a standard data-taking year. The resources requirements during the commissioning of the machine and the two first years of running have been estimated as a percentage of a standard data-taking year, taking into account the information available at this moment about the LHC machine schedule. Independently from the LHC \mbox{pp} luminosity, the beam parameters will be adjusted to achieve a luminosity of at most $3 \times 10^{30}\ \mathrm{cm}^{-2} {\mathrm s}^{-1}$ leading to an interaction of 200~kHz and an average pileup of about 36 events during the TPC drift time (88~$\mu $s). The parameters adopted for \mbox{Pb--Pb} collisions are listed in Table~\ref{CH7Tab:PbPb_parameters}. \vspace{-0.3cm} \begin{table}[ht] \begin{center} \vspace{-0.1cm} \caption{Parameters adopted for \mbox{Pb--Pb} collisions.} \label{CH7Tab:PbPb_parameters} \begin{tabular}{ll} & \\ Centre-of-mass energy & 5.5A~TeV \\ Luminosity & $ 5 \times 10^{25}\ \mathrm{cm}^{-2} {\mathrm s}^{-1}$ in 2008 \\ & $ 5 \times 10^{26}\ \mathrm{cm}^{-2} {\mathrm s}^{-1}$ (average luminosity) from 2009 onward \\ Total reaction cross-section & 8 b \\ Nominal collision rate & $4\times 10^{3}$ Hz \mbox{Pb--Pb} collisions at average luminosity \\ & \end{tabular} \end{center} \end{table} \vspace{-0.9cm} The trigger rate and RAW data bandwidth are independent of the luminosity as trigger thresholds and conditions will be adjusted to saturate the bandwidth. During \mbox{pp} collisions, more than one bunch crossing will happen during the gating of the TPC on account of its long drift time, and therefore more than one collision may be recorded (pileup). The amount of this pileup depends on luminosity, and therefore the event size will increase with the luminosity. Studies are under way to remove these pileup events on line with the HLT system. However, given the criticality of this operation, we do not foresee doing it in the first years of \mbox{pp} running. During the first year of operation, the following running scenario has been assumed. The first \mbox{pp} run will take place over a reduced time, from the beginning of July 2007 until the end of September 2007. Assuming the maximum luminosity allowed for ALICE, this first run will deliver 40\% of the \mbox{pp} data during a standard data-taking year. This run will be followed by a short \mbox{Pb--Pb} pilot run with reduced luminosity which will deliver at most 20\% of the \mbox{Pb--Pb} data we will collect in one standard data-taking year. The first \mbox{Pb--Pb} run with a still reduced luminosity will occur at the end of 2008, the second year of LHC operation. As we have explained this will not imply a reduction in the data rate, as we will adjust the trigger accordingly. These assumptions have been taken into account to establish the rampup of resources deployment required by ALICE. Below we shall discuss the following types of data: \begin{itemize} \item{\bf RAW}: raw data as recorded by the DAQ (real) or simulated (Monte Carlo, MC); \item{\bf ESD}: Event Summary Data as produced by the reconstruction program; \item{\bf AOD}: Physics Analysis Object Data derived from the ESD and similar to today's n-tuples; \item{\bf TAG}: Event tags for event selection. \end{itemize} As far as the basic RAW data parameters are concerned, for both \mbox{pp} and \mbox{Pb--Pb} an average acquisition rate is considered. During a \mbox{pp} run, the rate can go up to 500~Hz, however, this is in special cases and for a short period of time only. Since for \mbox{Pb--Pb} collisions the event size changes significantly with the centrality of the collision, a normalized rate, taking an average event size of 12.5~MB, is considered. This event size has been calculated assuming a charged-particle density of d$N$/d$y$ = 4000. The actual trigger rate will be the sum of several event types with different sizes and rates. The data taking parameters are summarised in Table~\ref{CH7Tab:Data_taking_parameters}. \begin{table}[ht] \begin{center} \caption{Data-taking parameters.} \vspace{0.5cm} \begin{tabular}{|l|r|r|} \hline & \mbox{pp}& \mbox{Pb--Pb}\tabularnewline \hline \hline Event recording rate (Hz)& 100& 100\tabularnewline \hline Event recording bandwidth (MB/s)& 100& 1250\tabularnewline \hline Running time per year (Ms)& 10& 1\tabularnewline \hline Events per year& 10$^{9}$& 10$^{8}$\tabularnewline \hline \end{tabular} \end{center} \label{CH7Tab:Data_taking_parameters} \end{table} \section{The computing model} The computing model is subject to change with time. During the first years of running, even if luminosities might be below the nominal luminosity, only slightly less data will be recorded than during runs with nominal luminosities. The reason is that selective triggers will become operational only after a necessary training period needed to understand the various detection systems. Data from this early period will be processed offline rather differently than data from later runs. Understanding the detectors and training of the alignment, calibration, reconstruction and analysis algorithms will required many processing passes by many physicists on a subset of raw data. This phase must be limited in time and followed by an early fast processing of the total set of available data to guarantee early access to physics results. This fast processing must, however, be complete to preserve the richness of the data and the discovery potential in the early run. Therefore, adequate computing must already be available when the LHC provides the first \mbox{pp} collisions. In the following we discuss an offline processing scenario, from which the required computing resources are estimated, and which we foresee to apply during standard data-taking years at nominal luminosities. We assume that a normal run period is split into: \begin{itemize} \item seven months (effective 10$^7$~s) of \mbox{pp} collisions, \item one month (effective 10$^6$~s) of heavy-ion collisions, and \item four months of winter shutdown. \end{itemize} The overall organized processing (calibration, alignment, reconstruction and scheduled analysis) is scheduled and prioritized in the ALICE Physics Working Groups (PWG) and by the ALICE Physics Board. The end-user analysis (sometimes called `chaotic analysis') is performed in the context of the PWGs and, in case of lack of resources, it is prioritized by the Physics Board. Depending on the middleware that will be in use at the time of LHC start-up, a more or less hierarchical organization of computing resources (Tier~0, Tier~1, Tier~2) will be in order. Although ALICE believes that most likely the democratic cloud model rather than the strict hierarchy of the MONARC model will prevail, the estimate of the required resources uses the concepts and names introduced by MONARC (see also Section~\ref{SEC:Distributed_computing}). \begin{itemize} \item Tier~0 provides permanent storage for the raw data, distributes raw data to Tier~1 and performs the calibration and alignment task and the first reconstruction pass. Our model foresees that one Tier~1 and one Tier~2 be co-located with the Tier~0 at CERN. \item Tier~1s outside CERN provide permanent storage of a copy of the raw data. All Tier~1s perform the subsequent reconstruction passes, the scheduled analysis tasks, and the reconstruction of \mbox{Pb--Pb} MC data; they have the responsibility for the long term storage of data processed at Tier~1s and Tier~2s. \item Tier~2s generate and reconstruct the simulated \MC data and perform the chaotic analysis. \item Tier~0, Tier~1s and Tier~2s provide short-term storage with fast access to multiple copies of active data, raw (only a fraction) and processed. \end{itemize} Although the scenario may change to adjust to the available computing resources and \grid middleware functionality at a given time, or to provide rapid feedback to physics results obtained during the initial reconstruction and analysis, it is unlikely that the estimated needs of computing resources will vary considerably. Changes of the order of up to 50\% in processing, short-term storage, or long-term storage must however be anticipated. Unexpected features in the operation of the \grid resources, which might result in efficiencies lower than anticipated, and which could not be predicted during the Data Challenges, could also require more or less important changes in the needed computing resources. To estimate the computing resources required by the present model, the efficiency factors for the usage of processors (CPU), short-term storage (disk), and long-term mass storage (MS) listed in Table~\ref{CH7Tab:Efficiency-factors} have been adopted. These are factors agreed by the LCG project and used by all the LHC experiments. \begin{table}[ht] \begin{center} \caption{Efficiency factors for the use of processors (CPU), short-term storage (disk), and long-term mass storage (MS).} \vspace{0.5cm} \begin{tabular}{|c|c|} \hline \multicolumn{2}{|c|}{Efficiency factors (\%) }\tabularnewline \hline \hline Efficiency for scheduled CPU & 85\tabularnewline \hline Efficiency for chaotic CPU & 60\tabularnewline \hline Disk utilization efficiency & 70\tabularnewline \hline MS utilization efficiency & 100\tabularnewline \hline \end{tabular}\end{center} \label{CH7Tab:Efficiency-factors} \end{table} \section{CPU requirements} \subsection{Parameter values} The ALICE Data Acquisition system will record \mbox{pp} and heavy-ion data at a rate of 100~Hz during the previously discussed effective time of 10$^7$ s and 10$^6$ s, respectively (see Table~\ref{CH7Tab:Data_taking_parameters}). The raw data size will vary with the trigger selection. The product trigger-rate times raw-data-size is limited by the maximum bandwidth available to transfer data to the mass storage system, 1.25~GB/s. The processing power required for the reconstruction of data, raw as well as \MC, has been estimated from the performance of the reconstruction algorithms presently in use and tested on \MC data. We have taken as a value 80\% of the present reconstruction times, which takes into account the optimization of the code and its increase in complexity within a reasonable safety factor. For \mbox{Pb--Pb} collisions an average charged-particle multiplicity of 4000 has been adopted. This is a conservative estimation based on the recent results from RHIC and the theoretical extrapolations at LHC energy. The real value might, however, be smaller as suggested by the RHIC data. The reconstruction algorithms are not yet entirely optimized, and they are not complete as they do not yet include calibration or alignment procedures. The figures quoted for reconstruction try to take these factors into account, considering the evolution of the code performance during the past years. During the first years there will be a full first reconstruction pass followed by a `second pass' which will in reality be composed of several short runs to tune the reconstruction programs based on the results of the first full pass. It is expected that the resources needed by this activity will correspond to a full reconstruction pass. Then we will run a second full reconstruction pass on all data of that year's run with final condition information. As time passes, we expect to improve our capability to derive good condition information soon after the first reconstruction pass. However, we also expect the need to reconstruct and analyse data coming from previous runs. So the estimation of three reconstruction passes is reasonable over the foreseeable lifetime of the experiment, if compound with the foreseen upgrade of the computing equipment (see Section~\ref{CH7:rampup}). The computing power required for analysis has been estimated based on a limited variety of \grid-enabled analysis use-cases performed during the Physics Data Challenges. Since the analysis algorithms will vary in complexity depending on the physics channel under study, the computing power for analysis will have to be revised once a larger set of analysis classes has been exercised on the \grid. A variation of a factor up to two must be anticipated. The computing power required for the generation of \MC data is better under control. It will be subject to changes only if the real charged-particle multiplicity differs substantially from the predicted by the HIJING \MC generator. Table~\ref{CH7Tab:CPU-parameters} lists the values adopted for the various parameters entering our estimation. The CPU power quoted for simulation includes event generation, tracking of particles through the detectors (an average value for the \gthree and FLUKA transport codes has been adopted), and digitization of the generated signals. \begin{table} \begin{center} \caption{Computing power required for the processing (simulation includes event generation, tracking and digitization) of the ALICE real and \MC data.} \vspace{0.5cm} \begin{tabular}{|c|c|c|c|} \hline \multicolumn{4}{|c|}{Processing power parameters}\tabularnewline \hline \cline{3-3} \cline{4-4} \multicolumn{2}{|c|}{}& pp& HI\tabularnewline \hline \hline Reconstruction& KSI2k$\times$s/event& 5.9& 740.0\tabularnewline \hline Chaotic analysis& KSI2k$\times$s/event& 0.6 & 8.3\tabularnewline \hline Scheduled analysis& KSI2k$\times$s/event& 16.0& 240.0\tabularnewline \hline Simulation& KSI2k$\times$s/event& 39.0& 17000.0\tabularnewline \hline Reconstruction passes& --& 3& 3\tabularnewline \hline Chaotic analysis passes& --& 20& 20\tabularnewline \hline Scheduled analysis passes& --& 3& 3\tabularnewline \hline \end{tabular} \label{CH7Tab:CPU-parameters} \end{center} \end{table} Chaotic analysis tasks are well-focused analyses performed by single users on a subset of the data, possibly residing entirely at given Tier~2 centres. Scheduled analyses tasks gather many analysis from users and thus require much more CPU power than single-analysis tasks. They are performed on the entire set of reconstructed data, once per reconstruction pass. To optimize data transfer, scheduled analysis is best performed at Tier~1 centres. \subsection{Raw-data processing strategy} The scheduled processing of raw data consists of the reconstruction of the raw data and the creation of ESD objects. %as described in %chapter~\ref{CH:Reconstruction}. %chapter~\ref{CH:Basic_Parameters_and_RAW_data_structure}. Although the processing strategies vary between \mbox{pp} and heavy-ion runs, they have in common that the first reconstruction pass must be fast and must start immediately after (for heavy-ion) or during (for \mbox{pp}) data taking to allow for rapid discoveries and to establish quickly the overall properties of the collisions. On the other hand, the first heavy-ion reconstruction pass must be finished well before the start of the next heavy-ion run (at least six months before) to be able to define from the data analysis the running conditions. For heavy-ion runs, this first reconstruction is preceded by a computing-intensive calibration and alignment task not exceeding one month in duration and taking place during heavy-ion data acquisition. The additional reconstruction passes will consist of a full-fledged reconstruction including fine tuning of all the parameters of the algorithms. Calibration and alignment tasks are performed quasi online on the events stored on a disk buffer at Tier~0. The size of this buffer is the equivalent of two days of heavy-ion data taking, i.e.\ 200~TB. \subsubsection{\mbox{pp} data processing} The data collected during \mbox{pp} runs, being less demanding in terms of computing resources than heavy-ion data for their reconstruction, will be processed online or quasi online during data taking (seven months according to our standard data-taking year) at the CERN Tier~0. The data temporarily stored on the Tier~0 disk buffer (one day of {\mbox Pb--Pb running is the equivalent of 10 days \mbox{pp} data taking) are processed, successively calibrated, and reconstructed. Reconstructed data will be kept for long-term storage locally at Tier~0 and distributed to the Tier~1s. The second and the third reconstruction passes will be distributed in Tier~1s and spread over a period of six months. \subsubsection{Heavy-ion data processing} Because of the much larger data recording rate in heavy-ion mode, online reconstruction of the entire set of data would require unaffordable computing resources. The first reconstruction pass will therefore last four months and can start immediately after the data taking ends, or even during the run depending on the performance of the calibration and alignment task. It is crucial that this first reconstruction ends well before the next heavy-ion run starts in order to allow for enough time to analyse the data and elaborate the new running conditions. We estimate that the time required for this is of the order of six months. The second and third reconstruction passes will be distributed in Tier~1s and can be done over a period of six months. Obviously, in such a scenario, \mbox{pp} and \mbox{A--A} reconstruction passes will be concurrent. Two different reconstruction tasks, one for \mbox{pp} and one for \mbox{A--A}, will be permanently active in Tier~1s, and at Tier~0 either the first \mbox{pp} or the first \mbox{A--A} reconstruction will be active (see the sketch of a possible processing scenario in Fig.~\ref{CH7Fig:Processing_Scenario}). \begin{figure} \centering \includegraphics[bb=50 250 444 771,scale=1.0]{chap7fig/scenarioBW.eps} \caption{Processing scenario used to estimate the resources required at Tier~0, Tier~1s and Tier~2s.} \label{CH7Fig:Processing_Scenario} \end{figure} The resources required to perform the ALICE \mbox{pp} and heavy-ion data reconstruction within such a scenario are listed in Table~\ref{CH7Tab:CPU}. \begin{table} [htb] \begin{center} \caption{Annual processing resources required to reconstruct and analyse the real \mbox{pp} and \mbox{A--A} data and to process (generation, reconstruction, and analysis) \MC data.} \vspace{0.5cm} \begin{tabular}{|c|c|c|c|} \hline & \multicolumn{3}{c|}{CPU (MSI2K)}\tabularnewline & Integrated& Average& Max.\tabularnewline \hline \hline MC (simulation+reconstruction)& 150& 12.0& 12.0\tabularnewline \hline Real reconstruction& 94& 7.8& 13.0\tabularnewline \hline Scheduled analysis& 96& 8.0& 8.4\tabularnewline \hline Chaotic analysis& 16& 1.3& 1.3\tabularnewline \hline Alignment \& calibration& 3& 0.3& 3.0\tabularnewline \hline \end{tabular} \label{CH7Tab:CPU} \end{center} \end{table} \subsection{\MC data simulation} The production scheme of \MC differs for \mbox{pp} and heavy-ion simulations. In the case of \mbox{pp} simulations, \MC data will be generated in an amount similar to that of collected real data (10$^9$ events per year). To avoid requesting a prohibitive amount of resources and also to enrich generated events with physics signal of interest, we have adopted a merging technique for heavy-ion simulation. Full-fledged, heavy-ion events are generated in a limited amount (10$^7$ events per year) in sets of different impact parameters (minimum-bias, peripheral, and central); these events are called the `underlying events'. The different signal events are then generated, merged into one underlying event, at the digits level, and the merged event is reconstructed in a single task. In this way, the underlying events can be reused several times. From the data challenges experience we have fixed to 10 the number of times an underlying event can be reused and preserve realistic event-to-event fluctuations. The \MC \mbox{pp} and heavy-ion events are typically generated and reconstructed at the Tier~2 centres. The annual resources required to process the \MC data (generation, reconstruction) are listed in Table~\ref{CH7Tab:CPU}. \subsection{Data analysis} Based on the experience of past experiments, the data analysis will consume a large fraction of the total amount of resources. At variance with the reconstruction and the simulation tasks, not all the analysis tasks can be easily scheduled as they will involve potentially all the physicists of the collaboration applying customized algorithms many times on subsets of the data of various sizes. This way of performing analysis is called chaotic analysis. However, it is foreseen to perform scheduled analysis during the same production tasks as the reconstruction passes and therefore over the entire set of data. This scheduled analysis will group in each pass all the official algorithms approved by the Physics Board. The time needed to analyse reconstructed events depends very much on the complexity of the analysis algorithm and on the overhead introduced by the \grid processing. The latter can only be predicted once the analysis on the \grid has been exercised with the final middleware and at the final scale. The processing power we have considered is an average value which can vary largely from one analysis to the other. To estimate the processing resources required for the analysis we have considered that 200 physicists will exercise their algorithms many times on a small fraction of the data and produce physics results on a larger subset of the data. We furthermore assumed that the various analyses launched by the physics working groups are performed only once over the entire set of reconstructed data. Scheduled analysis, regrouping many analysis tasks, will require a larger amount of computing power per event than chaotic analysis. Individuals will also perform analyses using computing resources available at their home institutes. These resources are not accounted for in the present evaluation of the requirements. The annual required resources to analyse real data are listed in Table~\ref{CH7Tab:CPU}. From the scenario sketched in Fig.~\vref{CH7Fig:Processing_Scenario}, we deduce in Fig.~\vref{CH7Fig:Processing_Profile} the profile of CPU resources required, including the ramp-up scenario. \begin{figure} \centering \includegraphics[bb=100 80 506 781,scale=0.6,angle=-90]{chap7fig/profileBW.eps} \caption{Profile of processing resources required at Tier~0, Tier~1s, and Tier~2s to process all ALICE data.} \label{CH7Fig:Processing_Profile} \end{figure} The final values of resources required during a standard year of running at Tier~0, Tier~1s and Tier~2s are summarized in Table~\vref{CH7Tab:Summary}. \section{Storage requirements} All data produced by the ALICE detector will be stored permanently for the duration of the experiment. This includes the raw data, a second copy of the raw data, one set of \MC data, reconstructed data from all reconstruction passes, analysis objects, calibration and condition data. A fraction of the produced data will be kept on short-term storage, providing rapid access to data frequently processed and for I/O dominated tasks. The media for permanent and transient storage will be decided according to the technology available. Currently the permanent storage medium is magnetic tape and the transient storage medium is disk. The ratio between disk and tape storage will change with time and will be dictated by the price--performance ratio. The parameters used to estimate the storage requirements are derived from the Data Challenge experience and are reported in %section~\ref{CH1:Data_taking_parameters} and in Table~\ref{CH7Tab:Data_taking_parameters} and Table~\ref{CH7Tab:sto_para}. \begin{table} \begin{center} \caption{Size per event and per year of raw data produced by the ALICE experiment in \mbox{pp} and in \mbox{Pb--Pb} runs and by the processing of raw and \MC data.} \vspace{0.5cm} \begin{minipage}[c]{\textwidth} \begin{center} \begin{tabular}{|l|c|c|c|c|c|c|} \hline \multicolumn{5}{|c|}{Real data (MB)}& \multicolumn{2}{c|}{\MC data (MB)}\tabularnewline \hline & Raw& ESD& AOD& Event catalogue& Raw& ESD\tabularnewline \hline \hline \mbox{pp} per event& 1.0\footnote{It is assumed that five events are piled up.}& 0.04& 0.004& 0.01& 0.4& 0.04\tabularnewline \hspace*{0.4cm} per year ($\times 10^9$)& 1.1 & \multicolumn{3}{c|}{0.18}& 0.4& 0.1\tabularnewline \hline Heavy-ion per event& 12.5& 2.5& 0.25& 0.01& 300& 2.5\tabularnewline \hspace*{1.6cm} per year ($\times 10^9$)& 1.4& \multicolumn{3}{c|}{1.0}& 3.0& 0.9\tabularnewline \hline \end{tabular} \end{center} \end{minipage} \end{center} \label{CH7Tab:sto_para} \end{table} \subsection{Permanent storage} Raw data from \mbox{pp} and heavy-ion runs are copied onto permanent storage at Tier~0. They are further exported to the external Tier~1s, each one keeping a fraction of raw data on permanent storage, thus providing a second copy. To cater for possible network interruptions, a disk buffer corresponding to the equivalent of 12 hours of heavy-ion data taking is foreseen in the DAQ cluster, and the equivalent of 2 days at the Tier~0. One copy of each reconstruction pass is stored on permanent storage at Tier~0 and external Tier~1s, most likely where they have been generated. One copy of \MC data is stored and distributed among the Tier~1s. The annual requirement for permanent storage in each Tier category is summarized in Table~\vref{CH7Tab:Summary}. These values correspond to the needs during a standard year of running. Tier~2s are not required to provide permanent mass storage. \subsection{Transient storage} The requirements for transient storage on fast access media depend very much on the computing model, on the balance of available distributed processing resources, and on the network bandwidth and occupancy. In the absence of \grid simulation tools, our estimates on needed transient storage capacities are based on the requirement to store on disks data that will be frequently accessed primarily through non-scheduled tasks. They include: \begin{itemize} \item a fraction of the yearly raw data stored at Tier~0 (2\%) and at each external Tier~1 (10\%); \item one copy of the calibration and condition data at Tier~0 and each external Tier~1; \item two copies of the reconstructed data (ESD) of two reconstruction passes distributed onto Tier~0 and Tier~1s transient storage; a fraction of the ESD reside on disk at Tier~2. \item all analysis objects (AOD, event catalogue) distributed at Tier~2s and Tier~1s where they have been produced; \item one copy of generated \MC data are distributed in Tier~1s; \item two copies of reconstructed \MC distributed at Tier~2s where they have been produced. \end{itemize} The overall transient storage capacities required during a standard data taking year in each Tier category are listed in Table~\vref{CH7Tab:Summary}. \section{Network} \subsection{Tier~0} Data from the ALICE DAQ are transfered to Tier~0 at a rate of 1.25~GB/s during heavy-ion runs and 100~MB/s during \mbox{pp} runs. The DAQ farm provides for sufficient disk storage (50~TB) to buffer the equivalent of 12 hours of heavy-ion data taking. The maximum network bandwidth into Tier~0 is therefore 10~Gb/s during the heavy-ion run and~0.8 Gb/s during the \mbox{pp} run. The 10~Gb/s lines scheduled to be installed between the ALICE experiment and Tier~0 and exclusively dedicated to the raw data transfer will be sufficient. Several kinds of transfer will contribute to the outgoing traffic from Tier~0 to external Tier~1s: \begin{itemize} \item the raw \mbox{pp} data export during the seven months of data taking leads to a rate of 55~MB/s; \item during the same time ESD data are exported at a rate of 3~MB/s; \item the raw heavy-ion data exportation during the month of data taking and the following four months of shutdown leads to a rate of 120~MB/s; \item during the four months of shutdown time ESD data are exported with a rate of 26~MB/s. \end{itemize} Data will be transferred simultaneously to every external Tier~1. This traffic results in a data transfer peak of 150~MB/s during the winter shutdown period. These values translate into a maximum outgoing network bandwidth of about 2~Gb/s (average over the year 1~Gb/s). A disk buffer of 200~TB is required at Tier~0 to store the equivalent of 48 hours of exported \mbox{Pb--Pb} RAW data. \subsection{Tier~1} The maximum incoming bandwidth required from Tier~0 into each Tier~1 is deduced from the discussion in the previous section to be 0.3~Gb/s assuming raw data are distributed in six Tier~1s. To the traffic from Tier~0 has to be added the traffic from Tier~2 exporting \MC data. Assuming that all \MC data are processed in Tier~2s and that there are on average 3.5 Tier~2s sending their locally produced data to a given Tier~1, this traffic amounts to 20~MB/s. The incoming bandwidth is therefore equal to about 2~Gb/s. Tier~1 exports ESD data to Tier~2 for analysis. Assuming that all the analysis is done in Tier~2s and that each Tier~1 serves all the Tier~2s, the traffic from one Tier~1 to the Tier~2s amounts to 3~MB/s and requires a maximum bandwidth of about 0.03~Gb/s. \subsection{Tier~2} The incoming and outgoing bandwidth for Tier~2 is deduced from the discussion in the previous section to be 0.01~Gb/s and 0.6~Gb/s, respectively. The requested network bandwidth for the various Tier categories is summarized in Table~\vref{CH7Tab:Summary}. It should be noted that we assumed that the network is 100\% efficient and operational 100\% of the time. The network infrastructure should make provision for upgrades made possible by an evolving technology. One element that makes this evaluation difficult is the duplication factor for disk files. It is clear that we cannot keep all the active data on disk without requiring an unreasonable amount of disk space. Data will be copied from Tier~1s permanent storage onto Tier~2s disk buffers. When the disk buffer is full, data will be removed and then copied again when needed. This may affect the network load between Tier~1s and Tier~2s and also between Tier~2s according to the end-user analysis pattern and the functionality of the middleware performing the file movement. \section{Ramp-up of resources} \label{CH7:rampup} The total amount of resources required by ALICE for the production of \MC data and the processing of real data in a standard year of running, are summarized in Table~\vref{CH7Tab:Summary}. A small overall safety factor of 10\% has been taken into account for all kinds of resources (CPU and storage). The staging of the offline resources (see Table~\ref{CH7Tab:rampup}) is dictated by the LHC heavy-ion schedule and is synchronized with the ramp-up of the DAQ online resources. \begin{table} [ht] \centering \caption{Estimates for the computing resources ramp-up scenario. The timing of the resources increase is tuned to have the resources required in a given year available for the start of the heavy-ion run. The share of CERN CPU resources between Tier~0 and Tier~1/2 is describe in the text.} \vspace{0.5cm} \begin{tabular}{|l|rrrr|} \hline CPU (MSI2K) & 2007 & 2008 & 2009 & 2010 \tabularnewline\hline\hline CERN Tier~0 & 3.3 & 8.3 & 10.8 & 14.0 \tabularnewline CERN Tier~1/2 & & & & \tabularnewline Ex Tier~1's & 4.9 & 12.3 & 16.0 & 20.9 \tabularnewline Ex Tier~2's & 5.8 & 14.4 & 18.7 & 24.3 \tabularnewline Total & 14.0 & 35.0 & 45.5 & 59.2 \tabularnewline\hline\hline Disk (TB) & & & & \tabularnewline\hline\hline CERN Tier~0 & 95 & 238 & 309 & 402 \tabularnewline CERN Tier~1/2 & 579 & 1447 & 1882 & 2446 \tabularnewline Ex Tier~1's & 2941 & 7353 & 9559 & 12426\tabularnewline Ex Tier~2's & 2042 & 5106 & 6638 & 8629 \tabularnewline Total & 5658 & 14144 & 18387 & 23903\tabularnewline\hline\hline MSS (TB/year) & & & & \tabularnewline\hline\hline CERN Tier~0 & 990 & 2475 & 3218 & 4183 \tabularnewline CERN Tier~1 & 463 & 1158 & 1505 & 1957 \tabularnewline Ex Tier~1's & 2779 & 6947 & 9031 & 11740\tabularnewline Total & 4232 & 10580 & 13754 & 17880\tabularnewline \hline \end{tabular} \label{CH7Tab:rampup} \end{table} Before the first heavy-ion run, 20\% of the nominal total resources are required to process pp data and to produce \MC data. ALICE foresees an early and short heavy-ion pilot run before the end of 2007 for which 40\% of the resources required at CERN must be available already in mid 2007. 40\% of the external resources must be available when the heavy-ion starts to take up the tasks of the CERN Tier~1 and Tier~2 which are not available during the heavy-ion run and during the first reconstruction pass (4 months after the heavy-ion run). \begin{table} [h] \begin{center} \caption{Summary of the computing resources required by the ALICE computing model during a standard data-taking year (reference year 2008).} \vspace{0.5cm} \begin{tabular}{|c|c|c|c|c|} \hline & CERN (Tier 0/1/2)& Tier~1s& Tier~2s& Total\tabularnewline \hline \hline CPU (MSI2k)& 8.3& 12.3& 14.4& 35.0\tabularnewline \hline Transient storage (PB)& 1.7& 7.4& 5.1& 14.1\tabularnewline \hline Permanent storage (PB/year)& 3.6& 7.0& --& 10.6\tabularnewline \hline Bandwidth in (Gb/s)& 10& 2& 0.01& - \tabularnewline \hline Bandwidth out (Gb/s)& 1.2& 0.03& 0.6& - \tabularnewline \hline \end{tabular} \label{CH7Tab:Summary} \end{center} \end{table} The first full heavy-ion run is foreseen during the last quarter of 2008. Even though beams with reduced luminosity with respect to the nominal LHC luminosity might be available, data will be taken at the maximum rated allowed by the DAQ nominal bandwidth. In addition, even if the event size is smaller than the size used to estimate the resources required by the computing model, we will saturate the available DAQ bandwidth by tuning the triggers to increase the event rates, in such a way as to collect faster the statistics required for the ALICE physics goals. It would be unreasonable to limit the physics reach of ALICE during the startup years by delaying the installation at CERN of the full computing capacity. The rampup of the external resources must follow the rampup of resources at CERN to avoid to accumulate data to be processed. Delaying the installation of external resources would deprive ALICE from the needed capacity to react quickly to unexpected discoveries. Therefore, 100\% of the required resources must be installed at CERN, as well as 100\% of the external resources, already in 2008 for the first \mbox{Pb--Pb} run. In 2009 and 2010, a 30\% increase is requested in Tier~1 and Tier~2 resources to be able to cope with the reconstruction of the data of the running year and previous years. The computing resources required at CERN include Tier~0, Tier~1 and Tier~2 type resources. The first pass heavy-ion reconstruction will be performed during the four months after the heavy-ion run at Tier~0 and requests all resources (7.5~MSI2k) available at the CERN Tier~0. During the same time no Tier~1/2 resources are requested at CERN. \section{Summary} The computing resources requirements in each Tier category are summarized in Table~\ref{CH7Tab:Summary}. Our resources deployment scenario from 2007 to 2010 is summarized in Table~\ref{CH7Tab:rampup}. The resources at CERN are shared between Tier~0, Tier~1, and Tier~2 services. The resources at CERN Tier~1 are sized larger than the resources requested in an average Tier~1, but are similar to those foreseen in the large Tier~1s, such as GridKa. The resources at CERN Tier~2 are of the size of the resources requested in an average Tier~2. The resources at Tier~0 have been evaluated to process the \mbox{pp} data quasi-on line, as specified by our Computing Model. Just after the end of the heavy-ion run, Tier~1 and Tier~2 services will be switched off at CERN and their resources will be exclusively devoted to Tier~0. In such a way, sufficient resources will be made available to perform the first-pass reconstruction of heavy-ion data within the four months following the heavy-ion run. This mode of operation (see Fig.~\ref{CH7Fig:Processing_Scenario}) will leave a sufficiently large time buffer allowing us to analyse data and to define the running conditions for the next heavy-ion run. Tier~1s perform scheduled tasks such as additional reconstruction passes and scheduled analysis. Tier~2s produce and process \MC data and perform unscheduled end-user analysis tasks. The processing outside CERN is balanced to cope with the absence of Tier~1 and Tier~2 resources at CERN during the first-pass reconstruction of heavy-ion data and to provide an uniform global CPU resource request in external Tier~1s and Tier~2s. The yearly requirement for permanent storage is not likely to change with time, whereas the disk storage capacity requirements might change depending on the performance of the upcoming mass storage systems on the one hand and on the performance of the \grid on the other.