Version
of 10th. September 1998
Prepared by
M. Aderholz (MPI), Katsuya
Amako (KEK), Eva Arderiu Ribera (CERN), L. Barone (Roma), G. Battistona
(Milano), Julian Bunn (Caltech/CERN), Joel Butler (FNAL), M. Campanella
(Milano), Paolo Capiluppi (Bologna/INFN), M. Dameri (Genova), D. Diacono
(Bari), A. di Mattia (Roma), U. Gasparini (Padova), Fabrizio Gagliardi (CERN),
Irwin Gaines (FNAL), Philippe Galvez (Caltech), C. Grandi (Bologna), Frank
Harris (Oxford/CERN), Koen Holtman (CERN), Veikko Karimaki (Helsinki), J. Klem
(Helsinki), M. Leltchouk (Columbia), P. Lubrano (Perugia), L. Luminari (Roma),
Michele Michelotto (Padua), Ian McArthur (Oxford), Harvey Newman (Caltech),
Steve O'Neale (Birmingham), Bianca Osculati (Genova), Laura Perini (Milano),
Jim Pinfold (Alberta), Les Robertson (CERN), Ruth Pordes (FNAL), Simona Rolli
(Tufts), Takashi Sasaki (KEK), L. Servoli (Perugia), R.D. Schaffer (Orsay),
Massimo Sgaravatto (Padova), Terry Schalk (BaBar), Jamie Shiers (CERN), Lucia
Silvestris (Bari), K. Sliwa (Tufts), C. Stanescu (Roma), Tim Smith (CERN/IT),
Krzysztof Sliwa (Tufts), Stig Topp-Jorgentsen (Oxford), Christoph von Praun
(CERN), Enzo Valente (INFN), Ian Willers (CERN), Rick Wilkinson (Caltech),
David O. Williams (CERN)
20 September 1998
Executive Summary
The MONARC Project will
attempt to determine which classes of Computing Models are feasible for the LHC
Experiments. The boundary conditions for the models will be the network
capacity and data handling resources likely to be available at the start of,
and during LHC running.
The main deliverable from
the Project will be a set of example "baseline" models. The Project
will also help to define Regional Centre architectures and functionality, the
physics analysis process for LHC Experiments, and guidelines for retaining
feasibility over the course of running. The results will be made available in
time for use in the Experiments’ Computing Technical Design Reports which are
due in 2002.
The approach taken in the
Project is to develop and execute simulations of the various candidate
distributed computing systems. The granularity of the simulations will be
adjusted according to the detail required from the results. The models will be
iteratively tuned in the light of experience. Simulation of the diverse tasks
that are part of the spectrum of computing in HEP will be undertaken. For this,
a simulation and modelling tool kit will be developed which will enable a full
understanding of the impact of the varying degrees of network saturation on the
models.
Chapter 1: Introduction
The LHC experiments have
envisaged Computing Models (CM) involving hundreds of physicists doing analysis
at institutions around the world. CMS and ATLAS also are considering the use of
Regional Centres, each of which could complement the functionality of the CERN
Centre. They are intended to facilitate the access to the data, with more
efficient and cost-effective data delivery to the groups in each world region,
using national networks of greater capacity than may be available on
intercontinental links.
The LHC Models encompass a
complex set of wide-area, regional and local-area networks, a heterogeneous set
of compute- and data-servers, and a yet-to-be determined set of priorities for
group-oriented and individuals' demands for remote data. Distributed systems of
this scope and complexity do not exist yet, although systems of a similar size
to those foreseen for the LHC experiments are predicted to come into operation
by around 2005 at large corporations.
In order to proceed with the planning and design of the LHC Computing Models,
and to correctly dimension the capacity of the networks and the size and
characteristics of Regional Centres, it is essential to conduct a systematic
study of these distributed systems. The MONARC project therefore intends to
simulate and study network-distributed computing architectures, data access and
data management systems that are major components of the CM, and the ways in
which the components interact across networks. MONARC will bring together the
efforts and relevant expertise from the LHC experiments and their R&D
projects, as well as from current or imminent experiments already engaged in
building distributed systems for computing, data access, simulation and
analysis.
The primary goals of this project are:
As a result of this study,
MONARC will deliver a set of tools for simulating candidate Computing Models of
the experiments, and a set of common guidelines to allow the experiments to
formulate their final Models.
Distributed databases are a
crucial aspect of the studies. The RD45 project has developed considerable
expertise in the field of Object Oriented Database Management Systems (ODBMS).
MONARC will benefit from this experience and cooperate with RD45 in the
specific areas where the work of the two projects overlaps. MONARC will
investigate questions which are largely complementary to RD45, such as network
performance and prioritization of traffic for a variety of applications that
must coexist and share the network resources.
Chapter 2: Objectives
A set of common modelling
and simulation tools will be developed in MONARC. These tools will be
integrated in an environment which will enable the LHC experiments to
realistically evaluate and optimize their physics analysis procedures, and
their Computing Models, basing them on distributed data and computing
architectures. Tools to realistically estimate the network bandwidth required
in a given Computing Model will be developed. The parameters that are necessary
and sufficient to characterize the Computing Model and its performance will be
identified. The methods and tools to measure the Model's performance, and to
detect bottlenecks, will be designed and developed, and also tested in
prototypes. This work will be done with as much as possible co-operation with
the present LHC R&D Projects, and current or imminent experiments.
The principal objective is
to determine a set of feasible models, and to provide a set of guidelines which
the experiments could use to build their respective Computing Models.
The subsidiary objectives
are:
Chapter 3: Workplan
3.1 Scope
MONARC aims to study
analysis models and architectures suitable for LHC experiments, in order to
contribute to their Computing Models in time for the updated version of CTP
(CTPR) scheduled around end 1999.
3.2 Interaction with other projects
The project involves
collaboration not only from the LHC experiments, but also from other HEP
experiments preparing to run in shortly (such as BaBar and CDF); these are
going to develop expertise in many of the fields of interest for LHC. Channels
for regular contact will be set up as soon as the project is approved, taking
advantage of collaborators who are members also of the collaborations of
interest.
The project has to interact
also with other teams: with RD45, with CERN Technology Tracking Team, and with
the CERN HPSS team, as explained in the section of this document devoted to
"Interactions with other Projects".
The project requires a
sizeable manpower contribution from CERN:
3.3 Working methods
The working methods to be
employed in MONARC are largely dictated by aspects of the Project’s structure:
MONARC working methods will
embody the following principles:
The principles and
requirements stated above lead naturally to a collaboration structure based on Working
Groups and on a Steering Group (composed by the Chairpersons of the
Working Groups together with the Spokesman and the Project Leader). The
Steering Group assures the integration of the different tasks that are pursued
separately in the various Working Groups and Institutes after the decomposition
of the activities.
3.4 Working Groups
The Working Groups are:
The interplay between the
different Working Groups and their activities and the need to coordinate the
decomposition/integration steps in the various iteration cycles, require that a
detailed schedule be established which coordinates the timing of the relevant
tasks. This schedule is therefore explained in the "Phases" section.
A summary of the Milestones and the Gantt chart will be provided in the
Schedule Chapter, after detailing the Tasks and SubTasks.
3.5 Phases of the Project
MONARC’s workplan is
divided into two main phases, the first lasting 9 months, the second lasting 6
months. The phases are described in detail in Chapter 10.
3.6 Scope
3.7 Starting Conditions
Chapter 4: Task
Definitions
4.1 Overview
The tasks are loosely
defined in time order. Interdependency is quite strong between all the tasks.
Although some can be run in parallel, constant feedback is needed between
almost all of them.
4.2 Task 1: Simulation and Modelling
Realistic simulation and
extensive modelling of the a priori possible distributed computing
systems are the most important tasks in the first phase of the project. The
goal is to be able to reliably model the behaviour of network given the assumed
physical structure of a given computer system and the complicated resource use
patterns, including third party traffic and the inherently stochastic manner in
which hundreds of the physicists would access the data in their analyses of the
LHC experiments. The network load, hardware and networking costs and the performance
of a range of possible computer systems, measured by their ability to provide
the physicists with the requested data in the required time are the main
metrics in enabling to evaluate the results of a scan of multidimensional space
of parameters which characterize the models. The goal is to narrow down a
region in this parameter space in which viable models can be chosen by any of
the LHC-era experiments.
|
FTE |
Affiliation |
|
1.2 |
Tufts |
|
0.3 |
Caltech |
|
|
|
|
1.5 |
TOTAL |
Table 4.2.1 Effort allocated to the Simulation and Modelling
Task
The planned research can be
divided into the following sub-tasks, where the activities are expected to
follow an iterative approach, with a complete cycle of the
design-development-modelling-validation steps for every model studied and every
simulation tool used.
Ideally one would like to use a small number
(preferrably 2-3) tools to be able to cross-check the results. There exist a
number of packages, for example, SoDA, MODNET, SES, COMNET, Ptolemy, Simple++,
PARASOL; some of which have been looked at by various groups within MONARC.
This work should be pursued vigorously, with a recommendation by the end of
1998, or so. SoDA, a simulation environment developed by Christoph von Praun at
CERN IT, is at present the leading candidate to become one of the chosen packages.
It is essential to decide
on the appropriate level of modelling complexity. This work should start
immediately, as it must run in parallel with the task of development of the modelling
tools. We anticipate that the models will include the details of data transfers
from the disk to CPU, hardware configurations, complex network connections with
varying availability of bandwidth depending on geographical topology, time and
varying level of quality of service implementations. It is also essential to
develop, as good as possible, models for data access patterns and analysis
patterns. Here, the importance of input from physicists involved in experiments
being part of MONARC cannot be underestimated. Also, experience from current,
or near future, large statistics HEP experiments should be examined.
Significant development
work might be required to extend the existing SoDA class libraries in order to
be able to describe the models which will be simulated. The goal is to have an
advanced set of simulation tools by Spring of 1999.
This sub-task will involve detailed
simulations performed with the adopted set of tools and agreed upon different
sets of input parameter values, in order to explore meaningfully the
multidimensional parameter space of variables which describe the computer
system models. The goal is to have be able to deliver to the experiments first
reliable results by the Summer of 1999.
4.2.5 SubTask: Validation.
This important step is
anticipated to be taking place in parallel with the first implementation of the
models. We expect preparations for this sub-task to begin almost immediately.
Designing the test-bed measurements with which one can verify the results of
model simulations, at first simple and then more complex, is of paramount
importance. There may be overlap here with designing of the test-bed
measurements with which to improve our knowledge of a number of parameters
which are needed as input to models of the computing systems.
The manpower needed to complete the
simulation and modelling task is expected to vary with the project's progress.
Initially, a significant number of people will have to be involved in the
design stage of the simulation tools, as well as in defining the analyses and
data access patterns which must be satisfied by the computing systems which
will be explored in this project.
We expect of the order of 5
FTE be involved in this stage, although it may take many physical persons who
will contribute only a fraction of their time. It is obvious that strong ties
to the experiments will be very important in this initial stage.
We anticipate a need for 3
FTE, preferably 3 software professionals, to help with the design and development
of the simulation tools. One person should be located at CERN, while the other
two are anticipated to work in outside institutions. The search for a
CERN-based modeller has already begun. Tufts University will co-ordinate the
simulation and modelling work within the US-ATLAS groups, and they started the
search for a full-time modeller, as well..
In the modelling phase we
anticipate the need of about 4-5 FTE, with 3 modellers involved, and additional
manpower coming from several people each contributing with a fraction of their
time. Those people will most likely be the same group as those involved in the
design stage.
Validation will be carried out by about 2-3
FTE. Again, we anticipate some overlap with the group of people who
participated in the design stage, as well as with the researchers involved in
test-bed measurements within this tasks project.
4.3 Task 2: Computing Model
Architecture
This task addresses the
design of the overall computing system for the Experiments. Components of the
task include:
|
FTE |
Affiliation |
|
0.3 |
Caltech |
|
0.3 |
Milano/INFN |
|
0.1 |
CERN |
|
0.4 |
Oxford |
|
0.3 |
FNAL |
|
0.2 |
Roma/INFN |
|
0.3 |
Tufts |
|
|
|
|
1.9 |
TOTAL |
Table 4.3.1 Effort allocated to the Computing Model
Architecture Task
4.4 Task 3: Analysis and Network
Process Design.
Analysis Process is the
ultimate goal of every experimental enterprise in the field of HEP while
addressing the "Computing" design. This task of the project will
address the definition of a few different approaches to the schemes of
"way of doing analysis" among the many possibilities afforded by new
(and perhaps unforeseen) computing technologies.
The task is a clear
"user driven" one, since the Physicist Analyser has a large degree of
freedom in his/her choices to get relevant results exploiting the better or
more efficient (from his/her point of view) methods and using every resource
he/she can catch. Nevertheless some procedures and priorities have to be fixed
(even if they will change during the time of the experiment) in order to get
reasonable analysis response in a reasonable competitive time.
The task will select some
different scenarios for the Analysis Process, taking into account:
In addition, this task will
address the definition of a set of values able to characterize the Analysis
Processes in strict connection with the different Computing Model
Architectures, being the correlation very strong.
In summary, the Task will
identify possible Analysis Processes defining where the Raw data reside, how
the Reconstructed Objects will be produced and stay, how and where the
selection of relevant data for the analyses will be accessed, and finally where
and how the Physicists will go through his/her analyses.
All of that will have to be
coded and parameterized for in the Simulation.
A very simple, and probably
unrealistic, example can better explain the task. Given a PByte/year of data,
an Analysis Group goes through the Tag Database (produced quasi-online)
selecting 1% of reconstructed objects created by the "Offline
Reconstruction". They need to go through the full 1% sample once per
month, producing an Analysis Object sample (reduced in number of events and in
size, e.g.) which contains relevant analysis information, refined by experience
and results from previous steps. Each component of the Group goes through the
selected Analysis Objects by his/her own, with his/her own timing, trying to
extract Results and/or personal sub-samples.
The timings, workaround,
consistence, residence, storage, CPU needs and efficiency of such an example
will be addressed by the present task which will try to schematically describe
some different (and affordable) possibilities.
All the Analysis Processes chosen
as possible and then to be simulated, either initially or later on during the
Project, will have to be sketched in clear diagrams of serial and/or cycling
steps.
|
FTE |
Affiliation |
|
0.4 |
Bologna/INFN |
|
0.3 |
Caltech |
|
0.3 |
Milano/INFN |
|
0.5 |
FNAL |
|
0.3 |
Tufts |
|
|
|
|
1.7 |
TOTAL |
Table 4.4.1 Effort allocated to the Analysis and Network
Process Design Task
The task will be performed
trough the following Work Packages or Subtasks which will embrace some or all
of the Phases described in the Workplan Chapter:
The aim of the task is to
exclude a priori Analysis Models that lead to unbelievable and/or clearly
unaffordable resources, even if projected to year 2005. E. g. an Analysis
Process that will require either a local desktop storage of hundredth of
Terabytes or a network bandwidth of more that a Gigabit/sec dedicated to every
analyzing Physicist is clearly to be ruled out for the purpose of the Project.
Task
Milestones: Two milestones are settled.
The First during Phase 1A of WorkPlan : Exclude obvious unfeasible Analysis
Processes.
The Second during Phase 1B/1C : Exclude less obvious unfeasible Analysis
Processes profiting of the experience gained during the progress of the
simulation.
The aim of the Task is to
identify some (eventually different) schemes of "User's" needs while
doing Analysis of Data. Some examples of that are the response time of a
Database Query, the ability (and willingness) of doing queries locally or
remotely (Regionally or Centrally), which tools and methods the End-User will
adopt. As an example, the task will identify the methods that better fit the
User behavior while doing analysis, trying to fix the range of parameters that
will avoid refusal (and divergence) of the Analysis Model.
a) Required Resources:
b) Task Deliverables : A range of
Constrained Parameters defining the User Behavior while doing Analysis.
c) Task Milestones : First milestone
during Phase 1B for initial simulation. Second milestone during Phase 1C to
refine different (some) ranges of parameters. Third milestone during Phase 2 to
settle final range of affordable User's requests.
d) Task Duration/Schedule : The task
will end with the Project, during Phase 2 (being eventually revisited for Phase
3) having a schedule as stated by the previous milestones.
The aim of the task is to
extract information from the current Experiments' Analysis Processes. E. g. the
number of concurrent Users doing analysis in present experiments will give some
constraint (scaled to LHC) on the range of parameters to be simulated. Many
other informations like the number of Analyzing Groups, their natural topology
etc. can be investigated and recorded.
a) Required Resources:
b) Task Deliverables : A range of
constrained parameters about the Groups of Analysis, the components of the
Groups, the Number of Analysis, the number of concurrent Users, the
distribution of Physicists in the Groups.
c) Task Milestones : The task has to be
completed during Phase 1B at most, with a possible rescue during Phase 2.
d) Task Duration/Schedule : A strong
relation is needed with other Experiments, mainly (but not only) those using
Hadron Colliders. The duration/schedule is connected to the milestones
previously stated and to the evolution of the Processes used by our Colleagues
that may suggest us some modification to the project simulation.
The aim of the task is to
identify a set of Analysis Processes that will meet the requirements coming
from LHC data processing. The Models will have to be expressed in terms of
clear diagrams. Such diagrams have to specify the input, output required parameters
and resources, as well as the locations of data and computing power. A strong
correlation between this task and the Computing Model Architectures is of
course to be taken into account, being the Network one of the major concerns.
As an example, where, when and how often the Physicist will access his/her own
sample of selected data has to be designed; moreover the behaviors of the
Analysis Groups has to be classified.
a) Required Resources:
b) Task Deliverables : A set of
feasible Analysis Processes for LHC treatment of data, suitable for simulation
according to the Computing Model Architectures defined by the present Project.
c) Task Milestones : The task will
spread all over the duration of the Project.
A First milestone is foreseen for Phase 1B when an Analysis Process for first
simulation is needed.
A Second milestone is due for Phase 1C when a set of Analysis Processes is
needed to understand the possible spread of Models.
A Third milestone is due during Phase 2 in order to refine the Analysis Process
possibilities taking into account the constraints given by the simulation
performed and by the technology and budget limitations.
Finally another (or more) milestone can be foreseen just before the end of the
Project or, eventually, for a possible extension to Phase 3.
d) Task Duration/Schedule : See
milestones.
The aim of the task is to
study and then define different schemes of use of the LHC Collaborations
Resources (Central and distributed) in order to guarantee that prioritized
Analysis will get what they need in due time. Regional Centres access, use of
the Network and Database distribution are the key parameters for this task. For
example, when an Analysis item (and Group) get scientific interest over the
others, the coordinating Analysis Team has to have the methods (and real
technical authority) to set priorities on Collaborator's resources and needs a
way to understand which schedule could give the result in time. While the skill
of Physicists is out of our control, the overall capacity of the Computing
System should be manageable.
a) Required Resources:
b) Task Deliverables : A set of rules
to access Collaboration's Computing Resources, together with suggested methods
to implement them. The rules have to be "tuned" to different Analysis
Resources and to different Computing Model Architectures.
c) Task Milestones : The task will end
with the Project, since the coordination and management of Resources is an item
intrinsically embedded into the Analysis Process.
A First milestone can be foreseen for Phases 1B-1C, when some different schemes
of Processes have to be simulated on distributed resources.
A Second milestone is certainly due for Phase 2 when priorities and schedules
have to be taken into account to get reasonable simulation results.
Some more and refined milestones will be necessary for the evolution to Phase
3.
d) Task Duration/Schedule : According
to previous milestones and to the evolution of distributed database Management
Systems during the Project's life.
The aim of the task is to
establish which parameters are more sensitive for the evaluation of Simulated
Analysis Models. This task is a clear hard one, since not only scientific
(technological) parameters have to be accounted, but also "political"
constraints have to be honored. The present Infrastructure, or the foreseen
one, in different participating Countries (Laboratories, Computing Centres,
Network, Man Power) have to be carefully considered.
An example can help understanding the task duties. The required money for
implementing a specific Analysis Process (onto a given Computing Model
Architecture) is only marginal if the ultimate goal of the Experiment at LHC is
faced: all of the resources put on game have to have also a national, not only
international, feedback.
Apart from that, the task
will try to produce a set of sensible parameters that can give a
"measurement" of the goodness of a specific Analysis Process. Such
parameters are naively identified at present as Costs, Man Power, Flexibility,
Reliability, Efficiency and finally Adherence to Physicist willing.
a) Required Resources:
b) Task Deliverables : A set of
stringent (technically) and loose (Institution affordable) parameters to
evaluate the different simulate Analysis Models.
c) Task Milestones : A First milestone
stating a preliminary set of parameters is needed during Phases 1B/1C.
A Second milestone is due during Phase 2 to specify the results of the
simulations in a measurable way.
A Third (and probably not definitive) milestone will be requested for Phase 3
of the Project.
d) Task Duration/Schedule : According
to previous milestones.
4.5 Task 4: Implement Testbeds and
Measure Critical Parameters
In order to accomplish the
analysis of computing models and to evaluate the impact of data distribution
schemes, testbeds have to be implemented, depending on a set of well defined
measurable parameters. Testbeds will be a limited size implementation of
computing models as selected in Task 3. Task 4.5 defines the stages of this
process.
|
FTE |
Affiliation |
|
0.3 |
Caltech |
|
0.15 |
Milano/INFN |
|
0.2 |
Bologna/INFN |
|
0.6 |
Padua/INFN |
|
0.2 |
FNAL |
|
0.2 |
CERN |
|
0.3 |
Roma/INFN |
|
0.2 |
Tufts |
|
|
|
|
2.15 |
TOTAL |
Table 4.5.1 Effort allocated to the Implement Testbeds and
Measure Critical Parameters Task
The task can be subdivided
in following subtasks:
This subtask will implement
several use cases based on different configurations for ODBMS distributed
computing model, and data access patterns related to different functionalities
like reconstruction and analysis.
Define which Testbeds will
be implemented in relation to:
Test beds will involve many
institutes that need to be ready for running the appropriate tests. There will
be defined procedures for managing the global setup and facilitating test bed
execution in remote sites. This global setup includes the configuration and
management of hardware and software in all the involved regional centres.
This subtask includes:
This subtask is in
collaboration with the simulation task. All parameters obtained in the
simulation phase will be verified in the different test beds. We believe that
parameters like network connection can not be properly simulated in the scope
of this project. The fact that these test beds are relying on the client/server
architecture of an ODBMS it is necessary to study also those configuration
parameters related exclusively to the ODBMS. This step will be done in close
collaboration with RD45 work.
Study parameters of ODBMS
which are involved in the testbeds, i.e. considering overheads, network
protocol latencies, etc.
Study parameters related to
the network and connection between regional centres.
Manpower: (the number will
come from the matrix of responsibility to be done.)
Equipment: the number will
come from the matrix of responsibility
Software
Travel
Network Cost
packages etc..
Each of these subtasks.
Main milestone:
4.6 Task: Steering Group
|
FTE |
Affiliation |
|
0.1 |
Bologna/INFN |
|
0.3 |
Caltech |
|
|
|
|
0.4 |
TOTAL |
Table 4.6.1 Effort allocated to the Steering Group Task
Chapter 5: Deliverables
Chapter 6: Resources
The resources required for
the Project are broken down into the five principal areas of activity:
Chapter 7: Schedule
The project’s two principal
phases are:
A third phase is now more
clearly envisaged as a further R&D project, aimed at prototype designs and
test implementations of the Computing Models. It will be the natural
continuation of this project; it is however definitely separated from it in
terms of deliverables. It should start at the completion of phase 2 and will
have duration of a couple of years.
7.1 Phase 1
The workplan for Phase 1 is
organized in three sub-phases
7.1.1 Phase 1-A, duration 2 months
This is a setup phase
and the following activities shall be carried on in parallel in time ( not in
isolation ):
are
needed for starting the simulation and study their modelling.
7.1.2 Phase 1-B, duration 3 months
This is a startup phase
with three activities going on in parallel:
These simulation startup
steps should in principle be followed by every group member of the Simulation
W.G.
7.1.3 Phase 1-C, duration 4 months
This phase is the first
cycle of modeling, to be performed on a set choosen models "MS2-MSn".
The modeling steps ( Code, Run, Analyze, Evaluate) will be preceeded by the
selection of the range of Models ( analysis processes and system input
parameters ), and followed by testbed validation of key results.
In parallel with the Simulation/Modeling and interacting strongly with it, the
following activities will be pursued:
At
the end of the modeling cycle, the results achieved shall be:
7.2 Phase 2
In this phase, two or three
cycles of simulation/modelling will be performed. In the following list we
summarise the items that will be addressed
At the end of Phase 2, the
deliverables of this project will be made available:
The detailed workplan for Phase
2 will be provided later, in a progress report which will be delivered at
the conclusion of Phase 1, in June 1999.
Chapter 8: Risk
Identification
Chapter 9: Management
and Organisational Responsibility
Chapter 10: References
Appendix 1: Detailed FTE
breakdown (Internal Use Only)
|
FTE |
Name(s) |
Affiliation |
|
|
1.2 |
Rolli, Sliwa, Somigliana, (modeller) |
Tufts |
|
|
0.3 |
Bunn, Galvez, Newman, Wilkinson, (DoE app.) |
Caltech |
|
|
|
|
|
|
|
1.5 |
TOTAL |
|
|
Table 4.2.1 Effort allocated to the Simulation and Modelling
Task
|
FTE |
Name(s) |
Affiliation |
|
|
0.3 |
Bunn, Galvez, Newman, Wilkinson, (DoE app.) |
Caltech |
|
|
0.3 |
Battistoni, Campanella, Perini |
Milano/INFN |
|
|
0.1 |
Williams |
CERN |
|
|
0.4 |
Harris, McArthur |
Oxford |
|
|
0.3 |
Butler, Gaines, Pordes |
FNAL |
|
|
0.2 |
Barone |
Roma/INFN |
|
|
0.3 |
Rolli, Sliwa, Somigliana |
Tufts |
|
|
|
|
|
|
|
1.9 |
TOTAL |
|
|
Table 4.3.1 Effort allocated to the Computing Model
Architecture Task
|
FTE |
Name(s) |
Affiliation |
|
|
0.4 |
Capiluppi, Giacomelli, Grandi |
Bologna/INFN |
|
|
0.3 |
Bunn, Galvez, Newman, Wilkinson, (DoE app.) |
Caltech |
|
|
0.3 |
Battistoni, Campanella, Perini |
Milano/INFN |
|
|
0.5 |
Butler, Gaines, Pordes |
FNAL |
|
|
0.3 |
Rolli, Sliwa, Somigliana |
Tufts |
|
|
|
|
|
|
|
1.7 |
TOTAL |
|
|
Table 4.4.1 Effort allocated to the Analysis and Network
Process Design Task
|
FTE |
Name(s) |
Affiliation |
|
|
0.3 |
Bunn, Galvez, Newman, Wilkinson, (DoE app.) |
Caltech |
|
|
0.15 |
Battistoni, Campanella, Perini |
Milano/INFN |
|
|
0.2 |
Capiluppi, Giacomelli, Grandi |
Bologna/INFN |
|
|
0.6 |
Gasparini, Michelotto, Sgaravatto |
Padua/INFN |
|
|
0.2 |
Butler, Gaines, Pordes |
FNAL |
|
|
0.2 |
Holtman, Willers |
CERN |
|
|
0.3 |
Barone |
Roma/INFN |
|
|
0.2 |
Rolli, Sliwa, Somigliana |
Tufts |
|
|
|
|
|
|
|
2.15 |
TOTAL |
|
|
Table 4.5.1 Effort allocated to the Implement Testbeds and
Measure Critical Parameters Task
|
FTE |
Name(s) |
Affiliation |
|
|
0.1 |
Capiluppi, Giacomelli, Grandi |
Bologna/INFN |
|
|
0.3 |
Bunn, Galvez, Newman, Wilkinson, (DoE app.) |
Caltech |
|
|
|
|
|
|
|
0.4 |
TOTAL |
|
|
Table 4.6.1 Effort allocated to the Steering Group Task