![](media/image1.png){width="1.1791666666666667in"
height="0.9131944444444444in"}Technical Report GriPhyN-2001-xxx

[www.griphyn.org](http://www.griphyn.org/)

GriPhyN Research for ATLAS

Year 2 Project Plan

ATLAS Application Group

GriPhyN Collaboration

&

Software and Computing Project

U.S. ATLAS Collaboration

12/18/2001

Version 2.76

Table of Contents

[1 Introduction 3](#introduction)

[1.1 Terminology used in this Document 4](#__RefHeading___Toc533299644)

[2 ATLAS Background and Personnel 4](#__RefHeading___Toc533299645)

[2.1 ATLAS Software Overview 4](#__RefHeading___Toc533299646)

[2.2 ATLAS Data Challenges 4](#__RefHeading___Toc533299647)

[2.3 Personnel 5](#personnel)

[3 Manager of Grid-based Data -- Magda
6](#manager-of-grid-based-data-magda)

[4 Grid -- Enabled Data Access from Athena
7](#__RefHeading___Toc533299655)

[5 Grid User Interface -- Grappa 8](#grid-user-interface-grappa)

[5.1 Grid Portals 8](#__RefHeading___Toc533299657)

[5.2 Grappa Requirements 8](#__RefHeading___Toc533299658)

[5.2.1 Use Cases 8](#__RefHeading___Toc533299659)

[5.2.2 Analysis and Specification 9](#analysis-and-specification)

[5.3 Grappa Use of Existing Tools 10](#__RefHeading___Toc533299662)

[5.3.1 XCAT Science Portal 10](#__RefHeading___Toc533299663)

[5.3.2 XCAT Design Changes for Grappa 11](#__RefHeading___Toc533299664)

[5.4 Grappa and Virtual Data 13](#__RefHeading___Toc533299665)

[6 Performance Monitoring and Analysis
13](#performance-monitoring-and-analysis)

[6.1 Grid-level Resource Monitoring 14](#grid-level-resource-monitoring)

[6.2 Local Resource Monitoring 14](#local-resource-monitoring)

[6.3 Application Performance 15](#__RefHeading___Toc533299675)

[6.4 Higher Level Predictive Services 15](#__RefHeading___Toc533299676)

[6.5 Grid View Vizualization 16](#grid-view-vizualization)

[7 Grid Package Management -- pacman 17](#__RefHeading___Toc533299679)

[8 Security and Accounting Issues 17](#__RefHeading___Toc533299680)

[9 Site Management Software 18](#site-management-software)

[10 Testbed Development 18](#testbed-development)

[10.1 U.S. ATLAS Testbed 18](#u.s.-atlas-testbed)

[10.2 iVDGL 19](#ivdgl)

[11 ATLAS -- GriPhyN Outreach Activities
19](#__RefHeading___Toc533299686)

[12 Schedule and Goals 20](#schedule-and-goals)

[12.1 ATLAS Year 2 (September 01 -- December 02)
20](#atlas-year-2-september-01-december-02)

[12.1.1 Goals 20](#goals)

[12.1.2 Infrastructure Development and Deployment
20](#infrastructure-development-and-deployment)

[12.1.3 Challenge Problem I 21](#challenge-problem-i)

[12.1.4 Challenge Problem II 22](#challenge-problem-ii)

[12.1.5 Dependencies 22](#dependencies)

[12.2 ATLAS Year 3 (September 02 -- December 03)
22](#atlas-year-3-september-02-december-03)

[12.2.1 Goals 22](#goals-1)

[12.2.2 Data Challenge and Virtual Data
22](#data-challenge-and-virtual-data)

[12.3 Overview of Milestones 23](#overview-of-milestones)

[13 Project Management 24](#project-management)

[13.1 Liaison 24](#liaison)

[13.2 Project Reporting 24](#project-reporting)

[14 References 24](#references)

24 24 24 24

# Introduction

The goal of this document is to provide a detailed GriPhyN -- ATLAS plan
for Year 2. Some high-level plans for Year 3 are also included.

As an application, ATLAS software is inherently fit for grid computing
with its distributed data and computing needs. As such, we have
developed a coordinated approach for the various US Grid projects,
namely PPDG, GriPhyN and iVDGL, focused on delivering the necessary
tools for the ATLAS Data Challenges (DCs).

These tools fall in several different categories. First, and mainly as
part of PPDG although it will be used for GriPhyN, is Magda -- the
Managaer for Grid-based Data. This tool is a data distribution
tool/sandbox that is being used for initial work in distributed data
management. It was developed to enable the rapid development of
components to support users, and as other project pieces reach maturity
they are easily incorporated. For example, GridFTP was recently
incorporated, and current testing using the Globus replica management
tools is underway, replacing original prototype code for both functions.
This is detailed in Section 3. Related to this is work to enable
data-access over the Grid from within the Athena infrastructure. This is
described in Section 4.

Second is Grappa, the Grid Portal for Physics Applications, is being
developed as a more user-friendly interface to job submission and
monitoring, and will interface to Magda in future development as well.
This work is based on the Indiana XCAT project, and is fully adaptable
to new developments in Grid software and in the ATLAS/Athena framework
itself. Initial work has focused on a simpler, web-based interface to
job submission, with easy access to scripting as well. This is fully
described in Section 5.

In the area of monitoring, there are several on-going efforts with
respect to different aspects of the problem. We are leading the joint
PPDG/GriPhyN effort in monitoring to define the use cases and
requirements for a cross-experiment testbed. In addition, we have been
evaluating and installing sensors to capture the needed data for our
testbed facilities internally, and determining what information should
be shared at the grid level, and the best ways to do this. At the
application level, much work has been done with Athena Auditor services
to evaluate application performance on the fly. For vizualizing
monitoring data, we have developed GridView to easily see the resource
avai9ability on the U.S. ATLAS Testbed. These efforts are detailed in
Section 6.

We have also been working on the development of many needed management
tools. Section 7 discusses Pacman, our package management system, which
is a candidate for the packaging of VDT. Section 8 addresses our
security approaches, or rather, our use of other people's work in
security, and Section 9 describes our approach to site management
software.

Section 10 describes testbed development.

Section 11 describes education and outreach activities.

##  {#section .unnumbered}

## Terminology used in this Document

Several acronyms are used within this document. They include the
following project related acroynms:

DC Data Challenge, defined by the ATLAS project

GG GriPhyN -- ATLAS goals as defined in this document

iVDGL International Virtual Data Grid Laboratory Project

PG PPDG -- ATLAS project goals, as defined by PPDG project plans

PPDG Particle Physics Data Grid Collaboratory Project

VDT Virtual Data Toolkit, developed by GriPhyN and supported by iVDGL

# ATLAS Background and Personnel

This section gives a basic overview to the ATLAS software, describes the
data challenges which drive the computing goals for ATLAS, and lists the
involved personnel.

## ATLAS Software Overview

[Neded a paragraph on basic software infrastructure.]{.mark}

## ATLAS Data Challenges

Our approach is to design GriPhyN deliverables and schedules in
coordination with and in support of the major software and computing
activities of the international ATLAS Collaboration. This work is being
done in close conjuction with specific Grid planning[^1] underway within
the U.S. ATLAS Software and Computing Project, which includes planning
for the Particle Physics Data Grid Project (PPDG). The milestones
driving the schedule are a series of "Data Challenges" with increasing
scale and complexity which test the capabilities of the distributed
software environment. They are described in Table 1 below.

Table 1 Schedule for ATLAS Data Challenges

  ----------------------- ----------------------- -----------------------
  DC0                     December 01 -- February Continuity check of
                          02                      ATLAS software

  DC1                     February 01 -- July 02  Major test of
                                                  production
                                                  capabilities; 1% scale
                                                  relative to final
                                                  system. Grid tools to
                                                  be used in analysis
                                                  phase.

  DC2                     January 03 -- September 10% scale test. Large
                          03                      scale production
                                                  deployment of
                                                  multi-tiered
                                                  distributed computing
                                                  services.

  Full Chain Test         July 04                 Test of full processing
                                                  bandwidth, from high
                                                  level trigger through
                                                  analysis. High
                                                  throughput testing of
                                                  distributed services.

  20% Processing Farm     December 04             Production processing
  Prototype                                       test with 100%
                                                  complexity (processor
                                                  count), 20% capacity
                                                  system relative to 2007
                                                  level. High throughput,
                                                  high complexity testing
                                                  of distributed
                                                  services.
  ----------------------- ----------------------- -----------------------

The goals of GriPhyN Year 2 are to support physicist-user access and
analysis of DC1 data using existing and soon-to-be deployed grid
middleware components and toolkit services.

##  {#section-1 .unnumbered}

## 

### 

### 

## Personnel

The ATLAS -- GriPhyN team, Table 2 , involves participation from a
number of individuals from ATLAS affiliated instititutions and from
computer scientists from GriPhyN university and laboratory groups. In
addition, there is significant joint participation with PPDG funded
efforts at ANL and BNL.

Table 2 ATLAS -- GriPhyN Application Group

  -------------------------------------------------------------------------------
  Name         Institution   Affliations         Role        Work Area
  ------------ ------------- ------------------- ----------- --------------------
  Rich Baker   BNL           PPDG, ATLAS         Physicist   Testbed, monitoring

  Randall      IU            GriPhyN             Computer    XCAT, GRAPPA
  Bramley                                        Scientist   

  Kaushik De   UTA           ATLAS               Physicist   GridView, Testbed

  Daniel Engh  IU            GriPhyN, ATLAS      Physicist   ATLAS applications,
                                                             GRAPPA

  Dennis       IU            GriPhyN             Computer    XCAT, GRAPPA
  Gannon                                         Scientist   

  Rob Gardner  IU            GriPhyN, ATLAS      Physicist   ATLAS applications

  John Huth    HU            GriPhyN, ATLAS      Physicist   Management

  Fred         IU            ATLAS               Physicist   ATLAS applications
  Luehring                                                   

  David Malon  ANL           PPDG, ATLAS         Computer    Athena Data Access
                                                 Scientist   

  Ed May       ANL           PPDG, ATLAS         Physicist   Testbed coordination

  Jennifer     ANL           GriPhyN, Globus,    Computer    CS Liaison,
  Schopf                     PPDG                Scientist   Monitoring

  Jim Shank    BU            GriPhyN, ATLAS      Physicist   ATLAS applications

  Shava        IU            GriPhyN             Computer    XCAT, GRAPPA
  Smallen                                        Scientist   

  Jason Smith  BNL           ATLAS               Physicist   Monitoring, Testbed

  Valerie      NU            GriPhyN             Computer    Athena Monitoring
  Taylor                                         Scientist   

  Alex Undrus  BNL           ATLAS               Physicist   Software Librarian

  Torre Wenaus BNL           PPDG, ATLAS         Physicist   Magda

  Saul Youssef BU            GriPhyN, ATLAS      Physicist   Pacman, ATLAS app.

  Dantong Yu   BU            PPDG, ATLAS         Computer    Monitoring
                                                 Scientist   
  -------------------------------------------------------------------------------

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

Section describes grid-enabled data access from Athena.

# Manager of Grid-based Data -- Magda 

Magda (MAnager for Grid-based Data) is a distributed data manager
prototype for grid-resident data. Magda is being developed by the
Particle Physics Data Grid as an ATLAS/Globus project to fulfil the
principal ATLAS PPDG deliverable of a production distributed data
management system deployed to users and serving BNL, CERN, and many US
ATLAS grid testbed sites (currently ANL, LBNL, Boston University and
Indiana University). The objective is a multi-point U.S. Grid (in
addition to the CERN link) providing distributed data services to users
as early as possible. Magda provides a component-based rapid prototyping
development and deployment infrastructure designed to promote quick
in-house development of interim components later replaced by robust and
scalable Grid Toolkit components as they mature.

These work statements refer to components of US ATLAS Grid WBS 1.3.3.3
(Wide area distributed replica management and caching) and WBS 1.3.5.5
(Infrastructure metadata management).

The deployed service will be a vertically integrated suite of tools
extending from a number of grid toolkit components (listed below) at the
foundation, through a metadata cataloging and distributed data
infrastructure that is partly an ATLAS-specific infrastructure layer and
partly a generic testbed for exploring distributed data management
technologies and approaches, to primarily experiment-specific interfaces
to ATLAS users and software.

Grid Toolkit tools in use or being integrated within Magda include
Globus GridFTP file transfer, GDMP replication services, Globus replica
catalog, Globus remote execution tools, and Globus replica management.

Magda has been in stable operation as a file catalog for CERN and BNL
resident ATLAS data since May 2001 and has been in use as an automated
file replication tool between CERN and BNL mass stores and US ATLAS grid
testbed sites (ANL, LBNL, Boston, Indiana) since summer 2001. Catalog
content fluctuates but is typically a few 100k files representing more
than 2TB of data. It has been used without problems with up to 1.5M
files. It will be used in the forthcoming ATLAS Data Challenges DC0 (Dec
2001-Feb 2002) and DC1 (mid to late 2002). In DC1 a Magda version
integrated with the GDMP publish/subscribe data mirroring package (under
development within PPDG and EUDG WP2) will be deployed. The principal
PPDG milestone for Magda is fully functional deployment to general users
as a production distributed data management tool in June 2002. The
principal GriPhyN/iVDGL milestone is Magda-based delivery of DC1
reconstruction and analysis data to general users throughout the US
ATLAS grid testbed within 2 months following the completion of DC1.

In addition to its role in early deployment of a distributed data
manager, Magda will also serve as a development tool and testbed for
longer term R&D in data signatures (dataset and object histories
comprehensive enough to permit on-demand regeneration of data, as
required in a virtual data implementation) and object level cataloging
and access. This development work will be done in close collaboration
with GriPhyN/iVDGL, with a GriPhyN/iVDGL milestone to deliver dataset
regeneration capability in September 2003.

In mid 2002 Magda development in PPDG will give way to an emphasis on
developing a distributed job management system (the PPDG ATLAS Year 2
principal deliverable) following a similar approach, and building on
existing grid tools (Condor, DAGman, MOP, etc.). This work will be done
in close collaboration with GriPhyN/iVDGL development and deployment
work in distributed job management and scheduling.

ATLAS GriPhyN/iVDGL developers plan to integrate support for Magda based
data access into the GRAPPA grid portal now under development (see
Section 4).

References:

Magda main page: <http://atlassw1.phy.bnl.gov/magda/dyShowMain.pl>

Magda information page: <http://atlassw1.phy.bnl.gov/magda/info>

PPDG BNL page: <http://www.usatlas.bnl.gov/computing/ppdg-bnl/>

# Grid -- Enabled Data Access from Athena

Athena is the common execution framework for ATLAS simulation,
reconstruction, and analysis. Athena components handle physics event
selection on input, and support event collection creation, data
clustering, and event streaming by physics channel on output. The means
by which data generated by Athena jobs enter grid consciousness, the way
such data are registered and represented in replica and metadata
catalogs, the means by which Athena event selectors query metadata,
identify logical files, and trigger their delivery\--all of these are
the concern of this connective layer of software.

Work to provide grid-enabled data access from within the ATLAS Athena
framework is underway under PPDG auspices. Prototype implementations
supporting event collection registration and grid-enabled Athena event
selectors were described at the September 2001 conference on Computing
in High Energy and Nuclear Physics in Beijing (cf. Malon, May, Resconi,
Shank, Vaniachine, Youssef, \"Grid-enabled data access in the ATLAS
Athena framework,\" Proceedings of Computing in High Energy and Nuclear
Physics 2001, Beijing, China, September 2001). An important aspect of
this work is that the Athena interfaces are supported by implementions
both on the US ATLAS grid testbed (using the Globus replica catalog
directly), and on the European Data Grid testbed (using GDMP, a joint
EDG/PPDG product).

# Grid User Interface -- Grappa 

Grappa is an acronym for Grid Access Portal for Physics Applications.
This work supports U.S. ATLAS Grid WBS 1.3.9 (Distributed Analysis
Development) work breakdown deliverables. The preliminary goal of this
project was to provide a simple point of access to grid resources on the
U.S. ATLAS Testbed. The project began in May 2001.

## Grid Portals

While there are a number of tools and services being developed for the
Grid to help applications achieve greater performance and functionality,
it still takes are great deal of effort and expertise to apply these
tools and services to applications and execute them in an everyday
setting. Furthermore, these tools and services rapidly change as they
become more intelligent and more sophisticated. All of this can be
especially daunting to Grid application users who are mostly interested
in performance and results but not necessarily the details of how it is
accomplished. One approach that has been used to reduce the complexity
of executing applications over the Grid is a *Grid Portal*, a web portal
by which an application can be launched and managed over the Grid (cf.
Ref. Error: Reference source not found). The goal of a Grid Portal is to
provide an intuitive and easy-to-use web (or optionally an editable
script) interface for users to run applications over the Grid with
little awareness about the underlying Grid protocols or services used to
support their execution.

#### 

#### Grappa Requirements

### evelop Use Case ScenarioUse Cases

In order to understand submission methods and usage patterns of ATLAS
software users, information will be collected from collaboration
physicists. This information (e.g. specifications of environment
variables, operating system, memory, disk usage, average run time,
control scripts, etc.) will be used to formulate scenario documents,
understandable by physicist and non-physicist alike. A collection of
such scenario documents then describes typical software usage patterns
of collaboration members. From this collection, a Grid Portal for the
submission and management of ATLAS physics jobs to the Grid can be
designed which will meet the needs of a large percentage of
collaboration members.

In order to facilitate the collection of such information a web form
will be created. The information collected will include: name, email,
files which must be staged (number & size), environment variables
settings (yes/no), specific OS required (yes/no), command line parameter
entry (yes/no), describe general flow of execution, job runtime details
(e.g. interdependencies), memory requirements, software requirements
(libraries, executables, etc.), additional comments and so on.

One such scenario has been developed for ATLSIM[^2], the Geant3-Fortran
based full simulation of the ATLAS detector. Many others are needed to
gain a complete understanding of how ATLAS users are likely to utilize
the Grid.

### Analysis and Specification

Requirements and specifications should be easily extrapolated from the
use case scenarios. However, based on initial considerations the
following requirements are likely to be included.

-   Ability to run all commonly used ATLAS executables (e.g. ATLSIM,
    Athena, ATLFast, etc.)

-   Ability to easily enter and store parameters and user annotations
    for re-use, Grid WBS 1.3.5.1 (Job configuration management and
    book-keeping)

-   Ability to authenticate using grid credentials

-   Ability to stage input files; Grid WBS 1.3.3.9 (Data access
    management)

-   Ability to enter hardware and software requirements per job

-   Ability for system to make a best choice as to where to run job from
    available grid resources

-   Ability to review output and errors in real time

-   Ability to kill a job mid-execution

-   Ability to access replica catalog tools

-   Ability to access monitoring tools

-   Ability to interface with mass storage devices (Grid WBS 1.3.3.12)

-   Ability to interface with new tools as they become available

This project does not propose to develop new software components to
fulfill such requirements, but rather to tie together existing
technologies and make them accessible via a single user interface. Tools
such as the Network Weather Service, Prophesy, NetLogger are examples of
existing software that might be utilized for job management via GRAPPA.
Additionally, technologies developed within the ATLAS collaboration such
as methods for grid-wide coherent data management (Grid WBS 1.3.3.5),
data distribution (Grid WBS 1.3.3.7), tools and services for data access
management (Grid WBS 1.3.3.9).

Some desirable features envisioned at the beginning of the project
included: provide a method for physicists to easily submit requests to
run high throughput computing jobs on either on simple grid resources
(such as remote machine) or more advance grid resources such as a Condor
scheduling system. Job submission should be a straightforward task, but
still allow for parameter entry and in some cases automatic variation
(for example, changing random number seeds for simulation jobs, PYTHIA
parameters, etc.). The portal was designed to allow submission of either
Athena or ATLSIM jobs. The user interface could be either a web or
script interface. While the user can enter information about operating
system and RAM requirements etc., the user does not have to select which
computer the job is to run on. Application Monitoring/Job Output -- logs
and other output should be returned to the user. The user should also be
able to check the status of the job as it is running. For example, the
user may look at the first few lines of output and decide to terminate
the job. Security/Authentication -- depending on the resource the user
may have an account on the computer, or Globus credentials. Resource
Management -- Make accessible to users a listing of available resources,
resource usage statistics, monitoring tools and accounting information
for all resources on the grid.

Summary of Grappa feature requirements:

1.  Provide a simple interface for physicists to submit and monitor jobs
    on the Grid

2.  Compatible with Athena architecture

3.  Compatible with GriPhyN -- PPDG reference grid architecture

### 

Grappa Use of Existing Tools

### XCAT Science Portal

The *XCAT Science Portal*[^3] is a tool for constructing Grid Portals
being developed by the Extreme! Computing Laboratory in the Computer
Science department at Indiana University[^4]. An initial prototype of
this tool has been created which allows users to build personal Grid
Portals and has been demonstrated with several applications. A
simplified view of the current architecture is illustrated in Error:
Reference source not found and briefly described below.

Figure 5‑1 XCAT Science Grid Portal Architecture

[]{.mark}

Currently, a user authenticates to the XCAT Science Portal using their
GSI proxy credential; a user's proxy credential is then stored at the
server so that the portal can perform actions on behalf of the user
(such as authenticating to a remote compute resource). After
authentication, the user can access any number of *active notebooks*
within their notebook database. An active notebook encapsulates the
execution of a single application; it is composed of a set of HTML pages
describing the application, HTML forms to specify the configuration of a
job, and *Jython* scripts for controlling and managing the execution of
the application. Jython is a pure Java implementation of the popular
scripting language, Python. The advantage of Jython is that it can
interface directly to Java and thus interface to Globus services using
Globus' Java **Co**mmodity **G**rid (**CoG)** kit[^5]. A common action
of a Jython script is to launch an *Application Manager* which acts as a
wrapper around non Grid-aware applications. The XCAT Science Portal
launches software components which have interfaces following the Common
Component Architecture (CCA) Forum's specifications, which allows them
to interact with and be used in high-performance computation and
communications frameworks[^6]. For a full description of the diagram and
the XCAT Science Portal, see Ref. Error: Reference source not found.

Currently, the XCAT Science Portal is being redesigned (see next
section) based on experience with the prototype implementation and
emerging requirements from ATLAS/GriPhyN. In parallel with long term
planning, prototype development involving the XCAT Science Portal is
underway. Using an initial scenario document for ATLSIM the following
was accomplished:

-   Using Globus credentials performed remote execution

-   Stored parameters

-   Ran ATLSim based on scenario doc

### XCAT Design Changes for Grappa

In order to provide a Grid Portal to ATLAS applications, Grappa will
build on top of the XCAT Science Portal technology. While the XCAT
Science Portal has been ported to several applications, in order to
support ATLAS applications, it will need to interface to the tools and
services being developed by GriPhyN and other Data Grid projects. While
the requirements of ATLAS applications hasn't been fully assessed (see
Section 5.1), the following describes a likely redesign of the XCAT
Science Portal based on preliminary input.

First, one of the major redesigns planned for the XCAT Science Portal
architecture will be a restructuring to a three-tier design as
illustrated in the Error: Reference source not found below.

  -----------------------------------------------------------------------
  Grid Portal

  Grid Services

  Resource Layer
  -----------------------------------------------------------------------

Figure 5‑2 XCAT layers

[]{.mark}

This will provide a cleaner design as *Grid Services* are separated out
from the *Grid Portal*. For example, instead of having the notebook
database inside the Grid Portal, it will be a Grid Service that resides
one layer below the Grid Portal. This will also provide greater
flexibility as it will be easier to integrate new tools as they become
available. In the case of Grappa, examples of Grid Services are Magda,
described in Section 4, and the Scheduler and Job Management services
described in Section 6. Based on initial considerations of design
requirements, the following other types of Grid Services requirements
are likely candidates.

-   **Job Configuration Management**: Service for storing parameters
    used to execute a job and user annotations for re-use (Grid WBS
    1.3.5.1). This feature is currently implemented in the current XCAT
    Science Portal but will need to be redesigned as a Grid Service in
    order to facilitate sharing of job configurations among users.

-   **Authentication Service**: The ability to authenticate using Grid
    credentials. The XCAT Science Portal currently supports a MyProxy
    interface for this.

-   **File Management**: Service to stage input files (Grid WBS
    1.3.3.9), interface with mass storage devices (Grid WBS 1.3.3.12),
    access replica catalog tools, etc. This will likely be the
    combination of several Grid Services. For example, Magda provides
    replica catalog access and GridFTP can be used to stage input files.

-   **Monitoring:** Stores status messages, output, and errors in real
    time such that they can be retrieved and/or pushed to Grappa and
    then displayed to the user. The XCAT Science Portal can currently
    interface to the XEvent service (also developed by the Extreme!
    Computing Lab). Other monitoring services as those described in
    Sections 7.1.2 and 7.1.3 are likely to be accessed as well.

Second, the redesign of the XCAT Science Portal will consider multi-user
access to the Grid Portal such that each user does not have to maintain
their own web portal server but can still manage their own data
separately from other users. Third, currently parameter management
within the XCAT Science Portal is optimized for a small number of
parameters. Since ATLAS applications are controlled by a large number of
parameters \[typically how many?\], a more sophisticated parameter
management interface will be need to be developed.

## Grappa and Virtual Data

Grappa could be well placed to be a user interface to virtual data and
is similar to the NOVA work begun at Brookhaven Lab on "algorithm
virtual data", AVD[^7]. If virtual data with respect to materialization
is to be realized, a data signature fully specifying the environment,
conditions, algorithm components, inputs etc. required to produce the
data must exist. These will be cataloged somehow (Virtual Data
Language), somewhere (Virtual Data Catalog), or the components that make
them up are cataloged and a data signature is a unique collection of
these components constituting the \'transformation\' needed to turn
inputs into output. Grappa could then interface to the data signature
and catalogs and allow you to \'open\' a data signature and view it in a
comprehensible form, edit it, run it, etc. Take away the specific
input/output data set(s) associated with a particular data signature and
you have a more general \'prescription\' or \'recipe\' for processing
inputs of a given type under very well defined conditions, and it will
be very interesting to have catalogs of these \-- both of the \'I want
to run the same way Bill did last week\' variety and \'official\' or
\'standard\' prescriptions the user can select from a library.

-   
-   
-   
-   
-   
-   
-   
-   
-   

## 

# Performance Monitoring and Analysis

Performance monitoring and analysis is an important component necessary
to insure efficient execution of ATLAS applications on the grid. This
component entails the following:

-   Instrumenting ATLAS applications to get performance information such
    as event throughput and identifying where time is being spent in the
    application

-   Installing monitors to capture performance information about the
    various resources (e.g., processors, networks, storage devices)

-   Developing higher level services to take advanatge of this sensor
    data, for example, to make better resource management decisions or
    to be able to vizualize the current testbed behavior

-   Developing models that can be used to predict the behavior of some
    devices or applications to aid in making decisions when more than
    one option is available for achieving a given goal (e.g.,
    replication management)

-   

-   

Many tools will be used to achieve the aforementioned goals. Further,
the performance data will be given in different formats, such as log
files and data store in databases. Additional tools will be developed to
analyze the data in the different formats. The focus of this work will
be on the US ATLAS testbed. Currently, we are gathering requirements and
use cases to get detailed information about what needs to be monitored
and traces, so as to identify the appropriate higher levels services
needed.

Monitoring can cover a wide variety of projects, and we are involved in
most levels. We are leading the joint PPDG/GriPhyN effort in monitoring
to define the use cases and requirements for a cross-experiment testbed,
see Section 6.1. In addition, we have been evaluating and installing
sensors to capture the needed data for our testbed facilities
internally, and determining what information should be shared at the
grid level, and the best ways to do this, as detailed in Section 6.2. At
the application level, much work has been done with Athena Auditor
services to evaluate application performance on the fly, as described in
6.3. Section 6.4 discusses some higher level services work in
predictoin, and Section 6.5 describes GridView, a visualization tool.

## Grid-level Resource Monitoring

At the Grid-level, several different types of questions are asked of an
information service. This can include scheduling-based questions, such
as what is the load on a machine or network or what is the queue on a
large farm of machines, as well as data-access questions like -- where
is the fastest repository I can download my file from?

As part of the joint PPDG-GriPhyN monitoring working group[^8] we have
been gathering use cases to define requirements for the information
system needed for a Grid-level information system, in part to answer
questions such as these. The next step of this work will be to define a
set of sensors for every facility to install, and to develop and deploy
the sensors and their interface to the Globus Meta-computing Directory
Service (MDS) as part of the testbed. The services, needed to make
execution on compute grids transparent, will also be monitored. Such
services include those needed for file transfer, access to metadata
catalogs, and process migration.

## 

## 

## Local Resource Monitoring

The different resources used to execute ATLAS applications will be
monitored to aid in accessing different options for the virtual data.
Initially, the following resources will be monitored with different
tools: System Configuration, Network, host information and important
processes:

-   System Configuration: Monitoring systems should perform a software
    and hardware configuration survey periodically and obtain the
    information on what software (version, producer) are installed on
    this system, what hardware is available. This will help the grid
    scheduling choose the right system environment for the system-depend
    Atlas applications.

-   Network Monitoring: the network monitoring system either sniffs
    passively on a network connection or actively creates network
    traffic to obtain information about network bandwidth, package loss,
    and round-trip time. There are many tools available for network
    monitoring, iperf, Network Weather Service, pingER and so on. We
    need to support the deployment of these testing and monitoring tools
    and applications, in association with the HENP network working group
    initiative, so that most of Atlas major network paths can be
    adequately monitored. The network statistics should be included in
    Grid information service so that Grid software can choose the
    optimized path for accessing the virtual data.

-   Host Monitoring: host information includes CPU load, Memory load,
    available memory, available disk space, and average disk I/O time.
    This information will help Grid scheduler and grid user to choose
    computing resource to run Atlas applications intelligently. Atlas
    facility manager will use this information for site management. The
    necessary information for Grid computing will be identified and
    deployed at Atlas testbed. See Grid Resource Monitoring.

-   Process Monitoring: Process sensors monitor the running status of a
    process, such as (number of this type of processes, number of users,
    when it starts). A process sensor might have threshold hold set up
    and trigger alarm when the threshold is reached. This monitoring
    information will prevent overloading system resources and recover
    system from failure. We need to monitor the important service
    daemon: Grid Ftp server, (as describe in the Grid Resource
    Monitoring), slapd server and web server.

The local resource monitoring effort needs to be coordinated with PPDG,
GriPhyN, iVDGL, EU DataGrid and other HENP experiments to ensure that
the local resource monitoring infrastructures satisfy the needs of grid
users and grid applications.

## Application Performance

The ATLAS applications will be instrumented at various levels to obtain
performance information on how much time is spent with between accesses
to data and used with different data.

First, some of the Athena libraries will be instrumented so to get
detailed performance information about file access and file usage. For
the case when the instrumentation overhead is small, the libraries can
be automatically used when specified in a user's job script. For the
case when the instrumentation overhead is large, the instrumented
libraries must be specified by the user; such libraries will not be used
by default.

Second, the Athena auditors will be used to obtain performance
information. The auditors provide high-level information about execution
of different Athena algorithms. Auditors are executed before and after
the call to each algorithm, thereby providing performance information at
the level of algorithm execution. Currently, Athena includes auditors to
monitor the cpu usage, memory usage and number of events for each Athena
algorithm. Athena also includes a Chrono & Stat service to profile the
code (Chrono) and perform statistical monitoring (Stat).

Hence, Athena will be instrumented at both the algorithm and libraries
levels to obtain detailed performance data.

## Higher Level Predictive Services

The trace data found in log files and performance databases will be used
to develop analytical performance models that can be used to evaluate
different options related to access to virtual data. In particular,
various techniques will be used such as curve fitting and detailed
analysis and modeling of the core ATLAS algorithms. The models will be
refined as more performance data is obtained. The models can be used to
evaluate options such as is it better to obtain data from a local site
for which it is necessary to perform some transformations to get the
data in the desire format or access the data from remote sites for which
one needs to consider the performance of given resources such as
networks and the remote storage devices. The analytical models would be
used to evaluate the time needed for the transformation based upon the
system used for execution.

## Grid View Vizualization

GridView is being developed at the University of Texas at Arlington
(UTA) to monitor the US ATLAS grid. It was the first application
software developed for the US ATLAS Grid Testbed, released in March,
2001, as a demonstration of the Globus 1.1.3 toolkit. GridView provides
a snapshot of dynamic parameters like cpu load, up time, and idle time
for all Testbed sites. The primary web page can be viwed at:

<http://heppc1.uta.edu/kaushik/computing/grid-status/index.html>

GridView has gone through two subsequent releases. First, in summer
2001, MDS information from GRIS/GIIS servers were added. Not all Testbed
nodes run a MDS server. Therefore, the front page continues to be filled
using basic Globus tools. MDS information is provided in additional
pages linked from this front page, where available.

Recently, a new version of GridView was released after the beta release
of Globus 2.0 in November 2001. The US ATLAS Testbed incorporates a few
test servers running Globus 2.0 as well as every Testbed site running
the stable 1.1.x version. GridView provides information about both types
of systems integrated in a single page. Globus has changed the schema
for MDS information with the new release. GridView can query and display
either type. In addition, a MySQL server is used to store archived
monitoring information. This historical information is also available
through GridView.

We will continue to develope GridView to match the needs of the US ATLAS
testbed. In the first quarter of 2002, we plan to set up a heirarchical
GIIS server based on Globus 2.0 for the Testbed. The primary server will
be at UTA which will collect and publish monitoring data for all
participant nodes through MDS services. This GIIS server will also store
historical data which can be used for resource allocation and scheduling
decisions. Information will be provided for visualization through
GridView and the Grappa portal.

In the second quarter of 2002, we plan to develop graphical tools for
better organization of monitored information. Performance optimization
of the monitoring scheme will be undertaken after the first experience
from DC0 and DC1. Integration of various grid services will be an
important goal.

The UTA GridView team is an active participant in the PPDG monitoring
group led by Schopf and Yu. We have developed two important use case
scenarios for Grid monitoring which will be implemented in 2002. Release
of core software for monitoring the Testbed will be done from UTA
through Pacman.

# 

# Grid Package Management -- pacman 

If ATLAS software is to be smoothly and transparently used across a
shifting grid environment, we must also gain the ability to reliably
define, create and maintain standard software environments that can be
easily moved from machine to machine. Such environments must not only
include standard Atlas software via CMT and CVS, must able also include
a large and growing number of "external" software packages as well as
grid software coming from GriPhyN itself. It is critical to have a
systematic and automated solution to this problem. Otherwise, it will be
very difficult to know with confidence that two working environments on
the grid are really equivalent. Experience has shown that the
installation and maintenance of such environments is not only labor
intensive and full of potential for errors and inconsistencies, but also
requires substantial expertise to install and configure correctly.

To solve this problem we propose to effectively raise the problem from
the individual machine or cluster level to the grid level. Rather than
having individual Atlas sites work through the various installation and
update procedures, we can have individual experts define how software is
fetched, configured and updated and publish these instructions via
"trusted caches." By including dependencies, we can define complete
named environments which can be automatically fetched and installed with
one command and which will result in a unified installation with common
setup script, pointers to local and remote documentation and various
such conveniences. Since a single site can use any number of caches
together, we can distribute the expertise and responsibility for
defining and maintaining these installation procedures across the
collaboration. This also implies a shift in the part of Unix culture
where individual sites are expected to work through any installation
problems that come up in installing third party software. The
responsibility for an installation working must, we feel, be shifted to
the "cache manager" who defined the installation procedure to begin
with. In this way, problems can be fixed once by an expert and exported
to the whole collaboration automatically.

Over the next year or so, and particularly in order to prepare for Data
Challenge 1, we will use an implementation of the above ideas called
"Pacman" to define standard Atlas environments which can be installed
via caches. This will include run-time Atlas environments, full
development environments and project specific user defined environments.
In parallel, we will work with the VDT distribution team and with Globus
to develop a second-generation solution to this problem that can be more
easily integrated with the rest of the GriPhyN grid tools.

# Security and Accounting Issues

We will work with the existing GSI security infrastructure to help the
Testbed groups deploy a secure framework for distributed computations.
The GSI infrastructure is based on the Public Key Infrastructure (PKI)
and uses public/private key pairs to establish and validate the identity
of grid users and services. The system uses X.509 certificates signed by
a trusted Certificate Authority (CA). By using the GSI security
infrastructure we will be compatible with other Globus-based projects,
as well as adhereing to a defacto standard in Grid computing. We will
work in close collaboration with ESNet and PPDG groups working on CA
issues to etablish and maintain grid certificates throughout the
testbeds. We will support and help develop a Registration Authority for
ATLAS -- GriPhyN users.

A related issue is the development of an authorization service for
resources on the testbed. There is much research on-going in this effort
[(Ref. Community Authorization Service, CAS, from]{.mark}
[Argonne)]{.mark} which we will closely follow and support when these
services become available.

# Site Management Software

The LHC computing model implies a tree of computing centers where "Tier
X" indicates depth X in the tree. For example, Tier 0 is CERN, Tier 1 is
Brookhaven National Laboratory, and Boston University and Indiana
University are "Tier 2" centers, etc. University groups are at the Tier
3 level and Tier 4 is meant to be individual machines. While the top of
this tree is fairly stable, we must be able to add Tier 3 and Tier 4
nodes coherently with respect to common software environment, job
scheduling, virtual data, security, monitoring and web pages while
guaranteeing that there is no disruption of the rest of the tree as
nodes are added and removed. To solve this problem we propose to define
what a Tier X node consists of in terms of installed ATLAS and grid
software and to define how the grid tools are connected to the existing
tree. Once this is done, we propose to construct a nearly automatic
procedure (in the spirit of Pacman or successors) for adding and
removing nodes from the tree. Over the next year, we will gain enough
experience with the top nodes of tree of Tiers to understand how this
must be done in detail. In 2002, we propose to construct the software
that nearly automatically adds Tiers to the tree.

# Testbed Development

##  U.S. ATLAS Testbed

The U.S. ATLAS Grid Testbed is a collaboration of ATLAS U.S.
institutions that have agreed to provide hardware, software,
installation support and management of collection of Linux based servers
interconnected by the various US production networks. The motivation was
to provide a realistic model of a Grid distributed system suitable for
evaluation, design, development and testing of both Grid software and
ATLAS applications to run in a Grid distributed environment. The
participants include designers and developers from the ATLAS core
computing groups and collaborators on the PPDG and GriPhyN projects. The
original (and current) members are the U.S. ATLAS Tier 1 computing
facility at Brookhaven Laboratory, Boston University and Indiana
University (the two prototype Tier 2 centers), Argonne National
Laboratory HEP division, LBNL (PDSF at NERSC), the University of
Michigan, Oklahoma University and the University of Texas at Arlington.
Each site agreed to provide at least one Linux server based on Intel X86
running Red Hat version 6.x OS and Globus 1.1.x gatekeeper software.
Each site agreed to host user accounts and access based on the Globus
GSI x509 certificate mechanisms. Each site agreed to provide a native or
AFS based access to the ATLAS offline computing environment, sufficient
CPU and Disk resources to test Grid developmental software with ATLAS
codes. Each site volunteers technical resource people to install and
maintain a considerable variety of infrastructure for the Grid
environment and developed software by the participants. In addition,
some of the sites choose to make the Grid gatekeepers as gateway to
substantial local computing resources via Globus job manager access to
LSF batch queues or Condor pools. This has been facilitated and managed
by bi-weekly teleconference meetings over the past 18 months.

The work of the first year included installation and operation of an
eight node Globus 1.1.x Grid; installation and testing of components of
the U.S. ATLAS distributed computing environment, development and
testing of PDSF developed tools. These included MAGDA, GDMP, alpha
versions of the Globus DataGrid Tool sets. Testing and evaluation of the
GRIPE account manager[^9], the development and testing of network
performance measurement and monitoring tools. The development,
installation and routine use of Grid resource tools e.g. GridView. The
development and testing of new tool for distribution, configuration and
installation of software: PACMAN. The testing of the Atlas Athena code
ATLFast writing and reading to Objectivity databases on the testbed
gatekeepers; testing and preparations for installation of Globus 2.0 and
associated DataGrid tools to be packaged in the GriPhyN VDT1.0;
preparations and coordination with the European DataGrid testbed, and
coordination with the International ATLAS Grid project. The primary
focus has been on developing infrastructure and tools.

The goals of the second year will include: Continuing the work on
infrastructure and tools installation and testing. A coordinated move to
a Globus 2.0 based grid. Providing a reliable test environment for PPDG,
GriPhyN and Atlas core developers. The adoption and support of a focus

on ATLAS application codes designed to exploit the Grid environment and
this testbed in particular. A principal mechanism will be the full
participation in the Atlas Data Challenge 1 (DC1) exercise. This will
require the integration of this testbed into the EU DataGrid and CERN
Grid testbeds. During the second half we expect to provide a prototype
grid based production data access environment to the simulation data
generated as part of DC1, thus a first instance of the US based
distributed computing plan for US offline analysis of ATLAS data.

##  iVDGL

The iVDGL project will provide the computing platform upon which to
evaluate and develop distributed grid services and analysis tools. Two
ATLAS -- GriPhyN institutions will develop prototype Tier 2 centers as
part of this project. Resources at those facilities will not only
support ATLAS specific applications, but also the iVDGL/GriPhyN
collaboration at large, both physics applications and CS
demonstration/evaluation challenges.

An important component of the US ATLAS grid effort is the definition and
development of the layer that connects ATLAS core software to grid
middleware.

# 

# 

# ATLAS -- GriPhyN Outreach Activities

We plan to join GriPhyN and iVDGL outreach efforts with a number of
on-going efforsts in high energy physics, including, the ATLAS Outreach
committee and Quarknet.

Provide ATLAS liaison and support for the GriPhyN Outreach Center[^10].

Discuss installation of GriPhyN and ATLAS software at Hampton
University, and involvement of Hampton University students in building a
Tier 3 Linux cluster.

# Schedule and Goals

Below we give a description of ATLAS-GriPhyN short-term goals.

## ATLAS Year 2 (September 01 -- December 02)

###  Goals

Before and during Year 2, during Data Challenges 1 and 2, ATLAS will
build up a large volume of data based on the most current detector
simulation model and processed with newly developed reconstruction and
analysis codes. There will be a demand throughout the collaboration for
distributed access to this dataset, particularly the reconstruction and
analysis products. In close collaboration with PPDG we will integrate
VDT data transport and replication tools, with reliable file transfer
tools of particular interest, into a distributed data access system
serving the DC data sets to ATLAS users. We will also use on-demand
regeneration of DC reconstruction and analysis products as a test case
for virtual data by materialization. These exercises will test and
validate the utility of grid tools for distributed analysis in a real
environment delivering valued services to end-users.

Collaboration with the International ATLAS Collaboration, and the LHC
experiments overall is an important component of the subproject. In
particular, developing and testing models of the ways ATLAS software
integrates with grid middleware is a critical issue. The international
ATLAS collaboration, with significant U.S. involvement, is responsible
for developing core software and algorithms for data simulation and
reconstruction.  The goal is the successfully integrate grid middleware
with the ATLAS computing environment in a way that provides a seamless
grid-based environment used by the entire collaboration.

###  Infrastructure Development and Deployment

Specify in detail the testbed configuration, and which projects and
people are responsible for creating it.

Completed before 10/01:

-   VDT1.0 (Globus 2.0Beta, Condor 6.3.1, GDMP 2.0)

-   Magda

-   Objectivity 6.1

-   Pacman

-   Test suite for checking proper install

-   Documentation

-   The above packaged with Pacman

Deploy VDT services with ATLAS add-ons on a small number of machines at
4-8 of sites, identifying a skilled person at each site who is
responsible for making this happen. Install this set of basic software
for 4-8 cites: ANL (May), BU (Youssef), BNL (Yu), IU (Gardner) in first
3 months (required), with UTA, NERSC, U of Michigan, and OU following as
their effort allows. The work plan is:

1.  Identify a node at CERN to be included in early testbed development.
    This will include resolution of CA issues, and accounts

2.  Define simple ATLAS application install, neatly package up a simple
    example using Pacman, including documentation, simple run
    instructions and a readme file. Sample data file and a working
    Athena job are needed. Ideally, several applications will be
    included. (Shank, Youssef, May)

3.  Provide an easy setup for large scale batch processing. This will
    include easy account/certificate setup, disk space, and access to
    resources. Ideally this will be done with a submission tool,
    possibly based on Grappa or included within Magda, but that may way
    until later in the year.

###  Challenge Problem I

Within ATLAS, Data Challenge 1 (January - July 2002) involves producing
1% of the full-scale solution. The code will run on single machines
without Grid interactions. Event generation will use the Athena
framework, while the Geant3-based detector simulation will use the
Fortran-based program. The result will be data sets that are of interest
to users in general, generating 10\^7 events using O(1000) PC's, with a
total data size of 25-50 TB.

The Year 2 GriPhyN-ATLAS Goal (-1) will include serving this data in an
interesting and useful way to external participants. The goal of -1 is
to allow limited reconstruction analysis jobs using grid job submission
interface.

1.  The data sample will need to be tagged with metadata as part of the
    DC1 production process.

```{=html}
<!-- -->
```
4.  Serve the data (and metadata) using Grid infrastructure file access
    and a well organized website. A solution similar to Magda with
    physics metadata on a file-by-file basis, with a command line
    interface to provision files. Note: we need to clearly define how
    much data storage will be required at each site, and what types of
    data should be accessible.

5.  Job submission with minimal smarts: This might be Grappa as remote
    job submission Minimal scheduling smarts will be added- for example,
    identify where the (finite set of large reconstruction input) files
    are located, and co-allocate CPU resources. A possible solution
    involves layering on top of dagman

6.  Coherent monitoring for the system as a whole:

-   Condor log files

-   Gridview

-   Nice real-time network monitoring with graphical display

###  Challenge Problem II

A query is defined to be an Athena-based consumer of ATLFAST data, along
with some tag that identifies the input dataset needed. In an
environment in which user Algorithms are already available in local
shared libraries, this may simply be a JobOptions file, where one of the
JobOptions (like event selection criteria) is allowed to vary.

Three possibilities will be supported by GriPhyN virtual data
infrastructure:

1.  The dataset exists as a file or files in some place directly
    accessible to the site where the consuming program will run. In this
    case, the Athena service that is talking to GriPhyN components
    (e.g., an EventSelector) will be pointed to the appropriate file(s).

```{=html}
<!-- -->
```
4.  The data set exists in some place remote to the executable. The data
    will be transferred to a directly accessible site, after which
    processing will proceed as in 1.

5.  The data set must be generated. In this case, a recipe to produce
    the data is invoked. This may simply be a script that takes the
    dataset selection tag as input, sets JobOptions based on that tag,
    and runs an Athena-based ATLFAST simulation to produce the data.
    Once the dataset is produced, processing continues as in 1.

### Dependencies

To be defined

##  ATLAS Year 3 (September 02 -- December 03)

### Goals

One goal of ATLAS Data Challenge 2 (January to September 2003) is to
evaluate potential worldwide distributed computing models. During DC2,
we will compare a \"strict Tier\" model with a full copy of ESD (some on
tape, some on disk) at each Tier 1 site, to a \"cloud\" model where the
full ESD is shared among multiple sites with all of the data on disk.

The second goal of Year 3 is to evaluate the virtual data needed to
reconstruct dataset results, and algorithms to evaluate their success.

### Data Challenge and Virtual Data

DC2 will use grid middleware in a production exercise scaled at 10% of
the final system.

The goal of GG-2 is virtual data re-creation, that is, the ability to
rematerialize data from a query using a virtual data language and
catalog. Some issues to be resolved:

1.  Identify which parameters need tracking to specify
    re-materialization (things making up the data signature such as code
    release, platform and compiler dependencies, external packages,
    input data files, user and/or production cuts).

```{=html}
<!-- -->
```
6.  Identify a metric for evaluating the success of re-materialization.
    For example, what constitutes a successful reproduction of data
    products? Assuming bit-by-bit comparison of identical results is
    impractical, what other criteria can be identified which indicate
    "good enough" reconstruction? For example, statistical confidence
    levels on key histogram distributions.

## Overview of Milestones

Here we list major milestones of both GriPhyN (GG) and PPDG (PG) grid
projects in relation to ATLAS data challenges (DC).

• Dec 02 GG0.1 VDT 1.0 deployed (basic infrastructure)

• Jan 02 GG0.2 Integration of CERN testbed node into US Atlas testbed

• Jan 02 -- July 02 DC1 Data creation, use of MAGDA, Tier 0-2

• July 02 -- June 03 PG2 Job management, grid job submission

• July 02 -- Dec 02 GG1 Serving data from DC1 to universities, simple
grid job sub.

• Dec 02 -- Sept 03 DC2 Grid resource mgmt, data usage, smarter
scheduling

• Dec 02 -- Sept 03 GG2 Dataset re-creation, metadata, advanced data
grid tools

• July 03 -- June 04 PG3 Smart job submission, resource usage

Table 3 ATLAS - GriPhyN and PPDG Schedules

  ---------------------------------------------------------------------------------------
                2001                2002               2003               2004         
  ------------- ------ --- ---- --- ------ --- --- --- ------ --- --- --- ------ ---- ---
                                                                                      

  PG1                                                                                  

  GG0                                                                                  

  DC1                                                                                  

  PG2                                                                                  

  GG1                                                                                  

  DC2                                                                                  

  GG2                                                                                  

  PG3                                                                                  

                                                                                       

  Data                                                                                 
  Management                                                                          

  Scheduling                                                                           
  ---------------------------------------------------------------------------------------

# Project Management

ATLAS -- GriPhyN development activity, as it pertains to US ATLAS, has
components in both Software and Facilities subprojects within the US
ATLAS Software and Computing Project.

## Liaison 

Refers to US ATLAS Grid 1.3.2 (liason between US ATLAS software and
external distributed computing software efforts).

A Project Management Plan describes the organization of the US ATLAS S&C
project. Liaison personnel for GriPhyN have been named for Computer
Science and Physics.

## Project Reporting

Monthly reports will be submitted to the GriPhyN project management. In
addition, annual reports will be generated which will give an accounting
of progress on project milestones and deliverables. Additional reports,
such as conference proceedings and demonstration articles, will be filed
with the GriPhyN document server.

# References

[^1]: U.S. ATLAS Grid Planning page:
    <http://atlassw1.phy.bnl.gov/Planning/usgridPlanning.html>

[^2]: GRAPPA: Grid Access Portal for Physics Experiments:

    Homepage:
    <http://lexus.physics.indiana.edu/griphyn/grappa/index.html>

    Scenario document
    <http://lexus.physics.indiana.edu/~griphyn/grappa/Scenario1.html>

[^3]: The XCAT Science Portal, S. Krishnan, *et al*., Proc. SC2001:

    <http://www.extreme.indiana.edu/an/papers/papers.html>

[^4]: Extreme! Lab, Indiana University:
    <http://www.extreme.indiana.edu/index.html>

[^5]: SciDAC CoG Kit Project, Gregor von Laszewski, Keith Jackson:
    <http://www.cogkits.org/>

[^6]: CCA: Common Component Architecture forum:
    <http://www.cca-forum.org/> ;

    At Indiana University: <http://www.extreme.indiana.edu/ccat/>

[^7]: Algorithmic Virtual Data (NOVA project), at BNL:

    <http://atlassw1.phy.bnl.gov/cgi-bin/nova-atlas/clientJob.pl>

[^8]: Joint PPDG-GriPhyN Monitoring Working Group:
    <http://www.mcs.anl.gov/~jms/pg-monitoring>

[^9]: GRIPE: Grid Registration Infrastructure for Physics Experiments:

    <http://iuatlas.physics.indiana.edu/griphyn/GRIPE.jsp>

[^10]: GriPhyN Outreach Center:
    <http://www.aei-potsdam.mpg.de/~manuela/GridWeb/main.html>