The purpose of this document is to establish a framework, within the MONARC project, for the development and eventual testing and validation of models for distributed computing using Regional Centres working together with the main computing facility for LHC experiments at CERN.

Given the existence of significant computing facilities outside CERN for LHC experiments, we envision a hierarchy of computing centres ranging from very large, expensive multi-service facilities to special purpose service facilities such as large PC farms.

We classify a computing centre in terms of the kinds of services, and the scale of services it provides. We define a "Regional Centre" (RC) to be a multi-service centre which provides significant resources and support for LHC data analysis. We expect there to be smaller "special service centres", which will provide facilities to address specific issues, for example Monte Carlo event generation or documentation support.

This document focuses on the Regional Centres.

In the following sections a number of acronyms and terms are used which need a clear definition. These terms are adopted for sake of clarity in the discussion, and may have a different definition from the same terms used by one or more experiments. This section defines the terms used in the context of this document.

Access (to data) vs. Retrieval (of data): "Data access" refers to the specific situation where event data are stored in a database management system. This implies the necessity of defining access patterns, evaluating access efficiency and enforcing access policies. Data retrieval refers to making available to a job, or a community, data previously archived in any form.

AOD (Analysis Object Data) refers to objects which facilitate analysis, but which by construction are not larger than 10 Kbytes. So, if an analysis requires information that does not fit in this limited size, this analysis should access other objects (possibly larger in size). A more traditional term for a collection of such objects is "micro-dst" or "ntuple".

Bookkeeping refers not only to production-related logging (such as tape numbers or filenames) but also to the complete set of information allowing the user to be aware of the nature and quality of the data analyzed. Examples of such information are the version of the reconstruction program used to process a dataset, the calibration constants the data have been reconstructed with, or on which files/tapes a dataset is stored.

Calibration Data refers to diverse kinds of information generally acquired online (which may be strictly calibration constants, or monitoring data) as well as special runs taken for calibration purposes. Cosmic ray runs are included in this category. Collections of normal event data used for alignment and calibration studies are not classified as calibration data.

Catalog refers to the collection of bookkeeping information and NOT to the Objectivity "catalog" (which is the list of full pathnames for all the database files in a federation). In this context a catalog might, or might not, be implemented in Objectivity itself. The catalog may be important as an added layer of functionality on top of the database, for instance mapping human readable easy-to-decipher information to filenames.

Data Caching refers to the capability of holding a copy of frequently accessed data on rapidly accessible storage medium, under algorithmic control to minimize data turnaround and maximize user response.

Data Mirroring refers to automatic procedures which maintain identical (synchronized) copies of (parts of) a database in two or more locations. One copy is normally regarded as the "master copy" and the others as "mirror copies".

ESD (Event Summary Data) refers to physics objects by construction not larger than 100 Kbytes. A more traditional term for this kind of object would be "mini-dst".

Retrieval (of data): see Access (to data) or Retrieval (of data) above.

Tags refer to very small objects (100 to 500 bytes) that identify (tag) an event by its physics signature. A Tag could, for example, be a set of 96 bits each tagging a given physics channel or it could be a set of 10 words with some packed overall information for an event. In this document the Tag is NOT a global object identifier (i.e. a set of bits identifying uniquely an object in a database). A more traditional term would be "nano-dst" or "ntuple" The border between AOD and Tags is well defined in size but less well defined in functionality.

Finally this document is dealing throughout with "official" data sets. So, for instance, "creation of AOD" means the AOD that is created for the collaboration or its analysis groups from larger data sets by the production team on the basis of criteria agreed upon in common analysis meetings. "Personal" data of any kind are not considered in this document.

The offline software of each experiment is required to perform the following tasks:

• data reconstruction, which may include more than a single step, such as preprocessing, reduction and streaming. Some of these steps might be done online;

• Monte Carlo production, which includes event generation, detector simulation and reconstruction;

• offline (re)calibration;

• successive data reconstruction; and

• physics analysis.

To execute completely and successfully the above tasks, many services are required. A partial list includes:

• (re)processing of data through the official reconstruction program

[requires CPU, storage, bookkeeping, and software support]

• generation of events

• simulation of events

[requires a lot of CPU, storage, bookkeeping, and software support]

• reconstruction of MC events [see point 1]

• insertion of data into the database

• creation of the official ESD/AOD/Tags

• updating of the official ESD/AOD/Tags under new conditions

• ESD/AOD/Tag access (possibly with added layers of functionality)

• data archival/retrieval for all formats

• data import/export between different Tiers(see below)

• bookkeeping (includes format/content definition, relation with the data base)

• database maintenance (including backup, recovery, installation of new versions, monitoring and policing)

• basic and experiment-specific software maintenance (backup, updating, and installation)

• support for experiment-specific software development

• production of tools for data services

• production and maintenance of documentation (including Web pages)

• storage management (disks, tapes, distributed file systems if applicable)

• CPU usage monitoring and policing

• database access monitoring and policing

• I/O usage monitoring and policing

• network maintenance (as appropriate)

• support of large bandwidth

• consulting and training support

We assume that there exists one "central site", CERN, which is able to provide all the various services (but not with enough total capacity to do all analysis related tasks).

The following steps happen at the central site only:

1. Online data acquisition and storage
2. Possible data pre-processing before first reconstruction
3. First data reconstruction

Other production steps (calibration data storage, creation of ESD/AOD/tags) are shared between CERN and the RCs.

The central site holds:

• a complete archive of all raw data

• a master copy of the calibration data (including geometry, gains, etc.)

• a complete copy of all ESD, AOD, and Tags preferably online

For a typical large LHC experiment, the data-taking estimate is:

• 1 PB raw data per year per experiment

• 10⁹ events (1 MB each) per year per experiment

• 100 days of data taking (i.e. 10⁷ events per day per experiment)

Current estimates for the capacity to be installed by 2006 at CERN in support of a single LHC experiment are :

• 520,000 SI95 for CPU, covering data recording, first-pass reconstruction, some reprocessing, basic analysis of the ESD, support for 4 analysis groups;

• about 1400 boxes to be managed;

• 540 Terabytes(TB) of disk capacity;

• 3 Petabytes (PB) of automated tape capacity; and

• 46 GB/s LAN throughput.

One can assume that 10 to 100 TB of disk space is allocated to AOD and Tags at the central site.

In the following, resources for a Regional Centre will be expressed in terms of percentage of the CERN central facility.

The primary motivation for a hierarchical collection of computing resources, called Regional Centres, is to maximize the intellectual contribution of physicists all over the world, without requiring their physical presence at the CERN. An architecture based on RCs allows an organization of computing tasks which permits physicists to participate in the data analysis no matter where they are located. A computing architecture based on RCs is also an acknowledgement of the facts of life about network bandwidths and costs. Short distance networks will always be cheaper and higher bandwidth than long distance (especially intercontinental) networks. A hierarchy of centres with associated data storage ensures that network realities will not interfere with physics analysis. RCs also help overcome problems related to providing support to physicists who are separated from CERN by separate time zones by providing consulting support that is relatively nearby. Finally, RCs provide a way to utilize the expertise and resources residing in existing computing centres, laboratories, and universities throughout the world. For a variety of reasons it is difficult to concentrate resources (not only hardware but, more importantly, personnel and support resources) in a single location. A RC architecture will provide greater total computing resources for the experiments by allowing flexibility in how these resources are configured and located.

A corollary of these motivations is that the RC model allows one to optimize the efficiency of data delivery/access by making appropriate decisions on processing the data

1. where it resides,
2. where the largest CPU resources are available, or
3. nearest to the user(s) doing the analysis.

Under different conditions of network bandwidth, required turnaround time, and the future use of the data, different choices among the alternatives (1) - (3) may be optimal in terms of resource utilization or responsiveness to the users.

The envisaged hierarchy of resources may be summarized in terms of tiers with five decreasing levels of capacity, capability, and support personnel:

Tier-0: CERN, which acts also as a Tier-1 centre;

Tier-1: a large Regional Centre serving one or more nations and providing a large capacity, and many services, including substantial production capabilities, with excellent support

Tier-2: smaller centres, serving a single nation, a physical region within a nation, or a logical grouping of tasks within a nation or physical region, providing less expensive facilities, mostly dedicated to final physics analysis

Tier-3: institute workgroup servers, satellites of Tier-2 and/or Tier-1

Tier-4: individual desktops

The presence of a Tier-1 and one or more Tier-2 centres in the same region (or country) is not a requirement of the model. The choice to set up a Tier-1 or one or more Tier-2 centres or a combination of both will depend on many factors, including economic and political considerations, which are beyond the scope of this document.

In the following we shall discuss the configuration and scope of Tier-1 Regional Centres in terms of capabilities, constituency, data and communication profile and dependency. We shall also give a profile of Tier-2 centres; we will not discuss lower tiers whose architecture is simpler and typically determined by local needs.

The distributed-hierarchical model of LHC computing described in this document is very amenable to planning and control and therefore maps reasonably well to production activities such as reconstruction, production of various physics objects for analysis, and production simulation. It also maps well to the national funding structures and perhaps also to the topology of networking bandwidth available today. It does, however, introduce some rigidity into the actual physics analysis activities since each of these is usually a world-wide effort. The Computational Grid technology that has recently emerged may be a good basis for building solutions that overcome some of the limitations of the model presented here. Much research and development is needed before these ideas reach can provide practical solutions. However, the distributed architecture that we are describing in this report should be easily adaptable to "grid computing" and, in fact, provides a framework for moving quickly to this style of computing, especially for physics analysis.

An RC should provide all the technical services, all the data services needed for the analysis and preferably another class of data services (Monte Carlo production or data reprocessing, not necessarily from raw data).

An RC could serve more than one experiment; this possibility has some implications which will be addressed later in this document.

The aggregated resources of all RCs should be comparable to CERN resources; we expect that there will be between 5 and 10 RCs supporting each experiment. As a consequence a RC should provide resources to the experiment in the range 10 to 20% of CERN (although the functionality provided by automatic mass storage systems might be provided differently).

Furthermore, an RC must be capable of coping with the experiments' needs as they increase with time, evolving in resource availability and use of technology.

The RC constituency consists of local and remote users accessing the RC services and resources. The present discussion applies equally to RCs serving one or more experiments.

Two general considerations influence the proposed scheme:

1. whether issues of network connectivity place one set of physicists, say those in the nation or geographic region where the centre is located, "closer" in terms of data access capability to the centre than to other collaboration resources.
2. how the centre was funded and whether the funding agency has particular requirements or expectations with respect to the priority of various constituents.

Because of these considerations, it might be appropriate to provide higher priority to serving people close to the centre who would otherwise have trouble getting resources and actively participating to the analysis.

Given this complexity, there are several possible "constituencies" which might be served by a RC with relative priorities depending on circumstances:

1. Physicists in the region where the centre resides: the analysis resources supplied to these physicists represent the region's

fair share of support for the experiment's data analysis.

2. The whole collaboration: this involves carrying out production activities and providing support services that represent the region's contribution to the common production and support effort.
3. Other Regional Centres and their constituents: where appropriate, this involves providing services to other RCs to avoid unnecessary duplication of services or effort.(In return, this centre would use the services of other RCs so that it did not have to duplicate their resources.) In particular, it is expected that Tier-1 centres will provide significant support and services to nearby Tier-2 centres.
4. Members of other regions: providing service on a "best effort" basis or on the basis of an agreement with the collaboration to members outside the region to maximize the effectiveness of the collaboration as a whole in carrying out the data analysis.

The centres will each need to reach agreement with their local physicists and with the collaborations they serve on how resources will be allocated and priorities assigned among various constituencies and activities.

In particular while a centre will primarily serve its local user base, this could result in significant inefficiencies and duplication if each centre attempts to provide equivalent access to all separate physics datasets and support for all physics groups.

A more effective strategy would involve some degree of specialization among the centres, focusing on those physics datasets of most interest to the local users but not attempting to service all needs. The worldwide collection of centres could share responsibility, with every physics dataset being provided at least once at a centre (and the most popular datasets being replicated more than once). This will require that centres provide some level of support to non-local users needing to access a physics dataset that may only be resident there. Strategies to allow resources to be allocated dynamically to these non-local jobs, in competition with the local job mix, must be developed. Examples of these strategies will be modeled as part of the MONARC simulation activities, to help provide guidance in planning these strategies.

An RC should maintain a large fraction of the ESD/AOD/Tags, possibly all of them for given physics channels in case of prioritized data access to defined analysis groups. As the LHC program unfolds, the RC will have to accommodate the increasing volume of data by expanding its storage and access capabilities with incremental (annual) funding and by managing the data so that parts of it that are not frequently accessed are either migrated to cheaper, less rapidly accessible (possibly archival) storage or dropped altogether from the repository based on agreements with the experiment.

An RC should maintain a fixed statistical fraction of fully reconstructed data. Storage of calibration constants are not a problem; they are a tiny fraction of the data (GB vs. TB). Moreover past experience shows that they are not used in physics analysis, once one trusts the reconstruction. Calibration data (special runs) should only be stored where calibration studies are performed. Bookkeeping data (the catalog) should be available locally and but synchronized throughout the entire collaboration. The RC should implement a mechanism of data caching and/or mirroring. Data caching, and mirroring of portions of the data, will be of great value in improving the speed of completing an analysis in cases where network bandwidth is limited. A distributed model of computing with several RCs makes caching possible, and will increase the efficiency experienced at any individual Centre.

The mechanism of data transfer from the CERN to the RC depends also on the underlying network capability. The RC should have high performance network with maximum available bandwidth towards CERN; at the same time excellent connectivity and throughput should be provided to the RC users.

Data sets should preferably be transported via network. If network bandwidth, cost or other factors made this unfeasible for all data needed at the RC, then priority should be given to network transfer of smaller datasets (ESD/AOD/Tags as long as they are produced); larger datasets could then be shipped on removable data volumes.

Data access at the RC should be fast, lest one looses all the advantage of computing at the RC. So, for example, if analysis service is concentrated on physics channels, all data needed for that channel should be online.

Software Collaboration: the RC must share common procedures for maintenance, validation and operation of production software. Site-specific issues, such as support for particular platforms not generally used by the collaboration or site-specific tools, are the sole responsibility of the RC.

The dependence of the RC on CERN can be further classified in terms of:

• data dependence;

• software dependence; and

• synchronization mechanisms.

Data Dependence: the obvious part concerns data that are copies of the data stored at CERN (ESD/AOD/Tags, reconstructed data, calibrations). These data are transferred to the RC regularly to fulfil RC services. Less obvious is "creation" of new data at the RC; example: reprocessing of data done at the RC, creation of official ESD/AOD/Tags for given analysis channel etc. In the latter case the RC holds a unique copy of these data until they are transferred to CERN. So, assuming the capability of RC to reprocess data with the official offline software, the management issues involved depend on policy decisions taken by the collaborations.

Software Dependence: the RC relies on delivery from CERN of the reconstruction and analysis software, through the appropriate mechanisms set up in the experiments.

Synchronization Mechanisms: this depends on the underlying event data base; For example, if it is Objectivity and if one has a single federation with CERN, then data will be synchronized by Objectivity's mechanisms. If one has different federations then synchronization becomes a management issue, and automatic procedures must be developed. In any case, the catalog must be kept continuously synchronized across all sites; this may be demanding in terms of network bandwidth, reliability and of backup procedures in case of network failure.

A Tier-1 centre may serve more than one experiment, and in particular more than one LHC experiment. Although this may be an advantage from the RC side (economy of scale, centralized resources, avoiding duplication), from the experiments' point of view attention must be paid to potential conflicts arising from sharing of the RC resources. The following points need careful discussion and definition:

1. how RC hardware resources are used, in particular which resources are "assigned" to an experiment (CPU, disks) and which are "shared" (tape robot, network devices);
2. how one will deal with long failures of resources "assigned" to a given experiment
3. what criteria govern the use of "shared" resources (time slots, on demand, other criteria)
4. how services and infrastructure are assigned (system management, backup policies, physical space, archiving)

The best approach to avoid potential conflicts is the development of Memoranda of Understanding between each experiment and the Regional Centre which defines in advance service levels, priorities, and procedures.

Some countries were not able to set up Tier-1 centres for financial reasons, but may still have available resources, financial and human, to contribute a relevant amount of computing at home. It might also happen that in large countries a major facility like a Tier-1 RC could be augmented by other smaller facilities, possibly financed by different agencies or funding sources.

It is then reasonable to envisage a lower level Regional Centres, which we refer to as Tier-2 Regional Centres.

A Tier-2 RC is similar to a Tier-1 RC, but on a smaller scale; its services will be more focused on data analysis and it can be seen as "satellite" of a Tier-1 RC with which it exchanges data. A Tier-2 RC

should have resources in the range 5 to 25 % of a Tier-1 RC, or about 2% of the CERN Tier-0 Centre.

In principle nothing prevents a large number of such centres to exist

for each collaboration; however overall management issues at the level

of the experiment must not be underestimated. This could in practice

set a limit on the total number of RCs to about 10, tier-1 and tier-2, for each experiment.

A Tier-2 RC should provide most of the technical services, but not at the same level as a Tier-1. Data services for analysis will be certainly the major activity in such a centre, while other data services might not be available.

The most likely user community for a Tier-2 RC would be a local one. It might be possible to envisage access to Tier-2 RCs from remote users under special conditions (e.g. breakdowns of a Tier-1, urgent need for special analysis etc.), but this should be considered exceptional.

Tier-1 RCs exchange data with CERN directly. Tier-2 RCs can receive data (AOD and tags mainly, a small fraction of ESD) from a nearby Tier-1 RC with which it partners or from CERN; they should send data only to their partnering Tier-1 RC. In this way validation and control procedures would be concentrated only in Tier-1 RCs, simplifying software installation and maintenance in Tier-2. Databases in Tier-1, either federated or independent, should be seen as major backups of CERN; databases in Tier-2, most likely independent, should be seen as temporary repositories for analysis purposes.

All the conditions described for Tier-1 apply to Tier-2; network bandwidth to the Tier-1 should be sufficient to allow for needed data exchange. Again data access should be fast and data sets should be transported via network; this requirement sets the appropriate bandwidth needed for proper functioning of a Tier-2 centre.

Service Centres are sites dedicated to specific services such as Monte Carlo production or re-calibration. Service Centres are supported by Tier-1 RCs where they send the data they produce. The availability of such data to the whole collaboration is managed by Tier-1 RCs. Service Centres will have an architecture optimized for the service they are intended to provide.

LHC era experiments, with unprecedented levels of size, complexity, and world-wide participation, demand new computing strategies. In particular, the collaborations must make effective use of resources, both human and machine, located throughout the world. This leads naturally to consider models where regional centres perform major portions of the computing activities.

The considerations discussed in this report suggest a need for regional centres with unprecedented amounts of computing resources. Nevertheless, the proposed scope for these centres is within the reach of several collaborating countries or regions and existing computing centres. This working document is the first step in a process to define and model these centres. Enough flexibility is allowed to accommodate the needs of different regions and experiments. We hope this encourages serious discussion and planning on the part of the experiments and prospective regional computing centres, as well as further consideration of the role of desktop systems and other portions of the total LHC computing environment.

In this appendix we show some architectural diagrams of a typical Regional Centre. Note that these are not meant to be physical layouts, but rather logical layouts showing the various work-flows and data-flows performed at the centre. In particular, services, work-flows and data-flows could be implemented at a single location or on a set of hardware components distributed over several different physical locations connected by a high performance network; this sort of virtual regional centre appears logically as a unique architecture to the user community.

To make the diagrams concrete, we provide a specific numerical example. The numbers in the example are at the rough scale of our current understanding of LHC computing requirements. However, these numbers should not be taken as actual estimates of the resources needed for any of the LHC experiments since the requirements for LHC computing are still being studied. Moreover, the numbers below do not include factors for down-time and uneven utilization nor do they take into account issues such as the need for "peaking capacity". With these caveats, the underlying assumptions behind the example shown are:

• Yearly data samples will be about 10⁹ total events, with raw event size of about 1 MByte;
• There will be a hierarchy of data types, ranging from raw data (RAW, 1MB/event), to reconstructed data (ESD - Event Summary Data, 100KB/evt), to physics data (AOD - Analysis Object Data, 10KB/evt), to ntuple like reduced data (DPD - derived physics data, 1-5KB/evt),to Tag data used for event selections (Tag, 200B/evt)
• All data will be initially reconstructed at the central facility (CERN), producing the initial ESD objects for all events. Initial creation of physics objects (AOD objects) will also be done at the central site. The regional centre will maintain copies of all AOD and TAG data, with some selection of RAW and ESD data based on the desires of supported physics groups
• Physics groups will choose certain events for re-reconstruction, i.e., for re-creation of a new version of the ESD objects with up-to-date calibration constants and algorithms. They will create their own selections of events, prepare AOD objects for their data samples, create official sets of DPD objects for analysis by many members of the physics group. These activities are mostly scheduled and predictable.
• Individual physicists will create private DPD data samples for further local analysis, and will analyze official and private DPD data at the desktop. These analyses may reference AOD data as well.
• Decisions will be made dynamically based on resource and data availability as to whether a particular computing job will be performed remotely or locally, and whether a particular data sample will be recreated from local data sets or moved over the network.

The overall architecture is shown in fig. 2. Production services are shown in the upper 80% of the diagram, consisting of data import and export, disk, mass storage and database servers, processing resources, and desktops. Support services are arrayed along the bottom of the chart, and include physics software development, R&D systems and test-beds, information and code servers, web and tele-presence servers,

and training, consulting, and helpdesk services.

Fig 3 charts the workflow at the centre, with individual physicists, physics groups and the experiment, as a whole, submitting different categories of reconstruction and analysis jobs, on both a scheduled and spontaneous basis.

Fig 4 shows an overview of the data-flow at the centre, where data flows into the central robotic mass storage from the data import facility (and out to the data export facility), and moves through a central disk cache to local disk caches on processing elements and desktops.

There are three different classes of parameters in the figures below: one that is in common for the entire experiment (although these parameters will vary from one experiment to another), such as size of event, total data volume, processing time per event, etc; a second class that varies from one regional centre to another, such as number of physics groups supported, amount of data replicated from the central facility, and aggregate amount of computing resources available; and a third class that is derived from the other two and cannot be varied independently.

Below, we show the calculations that led to the numbers in figures 3 and 4. The calculations are based on the current estimates of the requirements of ATLAS and CMS, which are subject to change as understanding continues to develop.

The three classes of parameters are identified as follows:

1. parameters between <> are fixed once and for all for each experiment. They can be varied as a whole for a single experiment to explore sensitivity of conclusions to assumptions.
2. parameters between [] are variable from one regional centre to another, depending upon the clients served by that centre.
3. other parameters are derived (by formula) from the [] and <> values and cannot be independently varied.

Considering the separate hardware components in detail:

[5%] of raw data X <1MB>/raw data event X <10⁹> events/yr) = 50TB/yr

[50%] of ESD data X <100KB>/event X <10⁹> events = 50TB/yr

[100%] of AOD data X <10KB>/event X <10⁹> events = 10TB/yr

[20%] recalculated ESD data X <100KB>/event X <10⁹> events = 20TB/yr

All revisions of ESD and AOD data,

assumed [10%] of events = 10TB + 1TB/yr

All simulated data, assumed

[50] samples of [10⁶] events X <2MB>/simulated event =100TB/yr

All recalculated ESD data: =10 TB/yr

All simulation ESD data: =10 TB/yr

All locally generated AOD data: =8 TB/yr

Selections of ESD, AOD and DPD data: [15] TB/yr

Selections of ESD, AOD and DPD data: [20] TB/yr

Raw data: [5%] of 1 year’s data (5X10⁷ events) = 50TB

Raw (simulated) data: all regional data (10⁸ events) = 200TB

ESD data: 50% of 2 year’s data = 10⁹ events = 100TB

AOD data: All of 2 year’s data = 2X10⁹ events = 20TB

Tag data: All: 2TB

Calibration/conditions data base (latest version): 10TB

Central Disk Cache: [100]TB

There is additional local disk cache on the various processing systems

and on desktops.

CPU power required for AMS database servers: [1000] SI95

These jobs process raw data and produce ESD (event summary data)

-Reconstruction of all simulated data from this region

[10⁸] events/year X <1000> SI95sec/evt = 5000 SI95

-I/O rate 5 event/sec X <1>MB/event in + <100>KB/event out = 5.5 MB/sec

-Re-reconstruction of [10%] of total data sample (as selected by physics groups)=10⁸ events X <1000> SI95sec/evt = 5000 SI95

-I/O rate 5 event/sec * <1>MB/event in + <100>KB/event out = 5.5 MB/sec

These jobs process ESD and most recent AOD data to select a sample of events of most interest to a specific physics group. Typically a 10% event sample (based on trigger type or initial Tag data) is reduced to a 1% sample in this step.

[10] physics groups X <10%> data sample (10⁸ events)X[3] passes/year

X 50 SI95sec/event = 5000 SI95.

I/O rate 150 event/sec X <100>KB/event in = 15MB/sec

These jobs process the ESD data from selected events (the 1% data samples selected above) and create the AOD (physics data) objects for these events.

[10] Physics groups X <1%> data sample (10⁷ events) X [8] passes/year

X <200> SI95/event = 5000 SI95.

I/O rate = 40 event/sec X <100>KB/event in + <10> KB/event out = 4.4 MB/sec

These jobs process selected AOD samples and produce the canonical

derived physics data samples (n-tuple equivalents) that are extensively used for private physics analysis.

[10] Physics groups X <1>% data sample (10⁷ events) X [20] passes/year

X 50 SI95/event = 3000 SI95.

I/O rate = 100 event/sec X <10>KB/event in + <10>KB/event out = 2MB/sec

These jobs process selected AOD and DPD data to prepare more refined private data samples together with analysis plots and histograms.

[200] physicists X <1%> data sample (10⁷ events) X [20] passes/year

X <20> SI95/event = 30000 SI95.

I/O rate = 2000 event/sec X <10>KB/sec in = 20MB/sec.

This does not include analysis done at the desktop which repeatedly

processes either the standard or private derived physics data to produce plots, several times/day.

Note the large amounts of processing power (and I/O bandwidth) needed for data analysis tasks; the requirements are significantly larger than the better-understood reconstruction tasks. Note also the large amount of disk storage associated with simulated events, even assuming the event generation and simulation is done in a distributed manner at local sites.

Total amount of CPU power at the regional centre for this example is roughly 10K SI95 for reconstruction, 20K SI95 for production analysis, and 30K SI95 for individual analysis (or .4, .8, and 1.2 TIPs) for a total of 2.4X10⁶ MIPs.