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

www.griphyn.org

GriPhyN Overall Project Plan

Version 10\
20 December 2001

Developed by members of the GriPhyN Project Team

Submit changes and material to:

Mike Wilde, editor\
wilde@mcs.anl.gov

Table of Contents

[1 Introduction 3](#introduction)

[2 The GriPhyN Vision 4](#the-griphyn-vision)

[3 Whats New Here? 5](#whats-new-here)

[3.1 The CS Research Program 5](#the-cs-research-program)

[3.2 The hard issues 6](#the-hard-issues)

[4 Core Technology Milestones 7](#core-technology-milestones)

[4.1 Virtual Data 7](#virtual-data)

[4.2 Request Planning 8](#request-planning)

[4.3 Request Execution 9](#request-execution)

[5 Project Participants and Structure
10](#project-participants-and-structure)

[5.1 Project Personnel 10](#project-personnel)

[5.2 Faculty 11](#faculty)

[5.3 Project Team Structure 11](#project-team-structure)

[6 Project Process Relationships 12](#project-process-relationships)

[6.1 Application analysis 13](#application-analysis)

[6.2 Infrastructure (testbed) construction
15](#infrastructure-testbed-construction)

[6.3 VDT Development 16](#vdt-development)

[6.4 Challenge Problem Identification
17](#challenge-problem-identification)

[6.5 Challenge problem solution 18](#challenge-problem-solution)

[6.6 Challenge Solution Integration 18](#challenge-solution-integration)

[6.7 Requirement Differences between Projects
18](#requirement-differences-between-projects)

[7 Coordination Between Grid Projects
19](#coordination-between-grid-projects)

[7.1 Coordination Regarding Virtual Data Toolkit
20](#coordination-regarding-virtual-data-toolkit)

[8 Project Logistics 20](#project-logistics)

[8.1 Coordination Meetings 20](#coordination-meetings)

[8.2 Communications 20](#communications)

[8.3 Planning 21](#planning)

[8.4 Reporting 21](#reporting)

[[9]{.mark} [Education and Outreach]{.mark} 21](#education-and-outreach)

[[10]{.mark} [Goals]{.mark} 24](#goals)

[[10.1]{.mark} [Remainder of Year 1 to September 30, 2001]{.mark}
24](#remainder-of-year-1-to-september-30-2001)

[10.2 Year 2: October 1, 2001 to September 30, 2002
24](#year-2-october-1-2001-to-september-30-2002)

[Appendix: Cost Sharing Arrangements
24](#appendix-cost-sharing-arrangements)

[Appendix: Risks, Contingencies, Critical Success Factors, Open Issues
25](#appendix-risks-contingencies-critical-success-factors-open-issues)

[[11]{.mark} [Removed Materials Beyond This Point]{.mark}
26](#removed-materials-beyond-this-point)

[[12]{.mark} [Progress -- June 1 2001 to Dec 31 2001]{.mark}
26](#progress-june-1-2001-to-dec-31-2001)

[[13]{.mark} [Remainder of Year 1 to September 30, 2001]{.mark}
26](#remainder-of-year-1-to-september-30-2001-1)

[13.1 Overall Goals 26](#overall-goals)

[13.2 Virtual Data Toolkit Development
26](#virtual-data-toolkit-development)

[13.3 Research Accomplishments 27](#research-accomplishments)

[13.4 Education and Outreach 28](#education-and-outreach-1)

[14 Year 2: October 1, 2001 to September 30, 2002
28](#year-2-october-1-2001-to-september-30-2002-1)

[14.1 Overall Goals 28](#overall-goals-1)

[14.2 Research Accomplishments 28](#research-accomplishments-1)

[14.3 Virtual Data Toolkit Development
28](#virtual-data-toolkit-development-1)

[14.4 ATLAS 28](#atlas)

[14.5 CMS 28](#cms)

[14.6 LIGO 28](#ligo)

[14.7 SDSS 29](#sdss)

[14.8 Education and Outreach 29](#education-and-outreach-2)

[14.9 Coordination 29](#coordination)

# Introduction

While GriPhyN is a research project, its scale and importance and its
complex relationships with other projects makes it important to identify
clear goals, milestones, and schedules, both for internal planning and
for use by our external collaborators. This document which we shall
revise periodically over the course of the project, provides this
information, and serves as a master-plan for the project. Its scope
includes all activities which are common to all four of the
participating science experiments. To supplement the master plan, all
activities which are specific to the GriPhyN interaction with each
experiment are described in a planning document for that experiment.
These planning documents each have the scope of 1 project year, running
from October 1 to September 30.

[The plan is structured as a set of yearly segments. For each,
we:]{.mark}

-   [Summarize overall goals, identifying in particular:]{.mark}

```{=html}
<!-- -->
```
-   [Challenge problems undertaken in experiments.]{.mark}

-   [VDT deliverables.]{.mark}

-   [CS research, with an indication of when they are expected to
    transition to VDT and experiments.]{.mark}

```{=html}
<!-- -->
```
-   [Specify specific milestones and deliverables.]{.mark}

-   [Indicate dependencies on other projects.]{.mark}

-   *[No longer true -- decribe instead the doc structure and refer to
    the detailed planning documents]{.mark}*

Some of the work to be undertaken by GriPhyN will be performed in
collaboration with participants in PPDG, EU Data Grid, and DOE SciDAC,
as well, of course, the four physics experiments with whom GriPhyN is
partnered. We indicate what components we expect to be produced by these
projects, and appropriate contingency plans if these components are not
forthcoming. We also hope to work in partnership with the proposed GRIDS
Center to provide support for our VDT, and with the proposed iVDGL
project to create and operate testbeds.

[The order of material in this document is as follows:]{.mark}

[- enunciate goals and vision, and CS basis for achivieing them (sec
2-4)]{.mark}

[- lay out the broad framework of the plan (sec 5-]{.mark}

[- discuss the approach for converting CS research into experiment
value]{.mark}

# The GriPhyN Vision

The goal of GriPhyN is to increase the scientific productivity of
large-scale data intensive scientific experiments through these
Grid-based approaches:

-   [Bring order to scientific data management through the concept of
    virtual data (reword)]{.mark}

-   Bring the power of the grid to bear on the scale of science data
    processing and management, by taming the grid for science

The science projects that we target share the common need to harness
large-scale distributed resources through data grid technologies. We
state an approach to doing this by describing what the four GriPhyN
experiments should look like when the results of GriPhyN are in place.

This vision has a direct bearing on our project planning effort. If the
scenarios described below depict the end goals of this project, we must
create a year-by-year plan that clearly identifies how we'll develop the
specified capabilities. This will demand a lot of inter-related and
inter-working technologies and components, and will require that we
solve research problems in a manner that creates solutions for the
missing pieces of this puzzle.

Each step in our plan needs to fit clearly into building the type of
solutions that we have described in the following scenarios.

Scientists can harness significant grid resources with little knowledge
of the complexities of resource allocation and distributed computing.

*Example: a CMS physicist can look in a catalog for simulation results.
Some of the results they want might be already at their site; others may
be at other sites and can be fetched quickly. Still others existed at
one time and can be re-derived; the remote network to yet another set of
results is going to be congested with a major transfer for the next 8
hours, so a new computation is kicked off to re-derive some of these
results, which will finish in 1 hour. The new computation uses 75% local
resources, the remaining resources are from remote sites with available
cycles on uncongested network paths.*

The analysis job that needs to run in these results is scheduled and
initiated when all data dependencies have been located or materialized.
This job runs at 4 different sites, and the final result is emailed to
the scientist in the morning. The scientist can check status of the
computation at any point, can stop or pause the job; sometimes even
steer it.

Experiment data is tracked in a uniform manner, clearly identifying how
most data objects were derived. *Example: A scientist questioning the
validity of an analysis can look in the catalog, find that the analysis
was based on 1000 event reconstructions, and can check which version(s)
or reconstruction code was used to create each of the 1000 events. She
discovers that 15 events were reconstructed using outdated code, and she
initiates a new reconstruction for these events, keeping the new data in
a private store. She then notifies her data administrator of the
problem, pointing him to the new events; the DA then replaces the
outdated reconstructions. He also interrogates the catalog to look for
similar events that require upgrading.*

**Resource allocations are controlled, measured and tracked by resource
administrators who set policies to achieve and arbitrate the overall
goals of both the experiment's virtual organization and the resource
owners.** *These policies are not excessively complex to express and
maintain, and they control the way in which the grid machinery executes
user requests.*

**Scientists use end-user-oriented tools and express their jobs in
science terms rather than in CS terms**. *Scientists should say: I want
to run code X on data Y. The automated grid " planner" mechanism should
decide where to get the data from, where to run the code, when to run
the code, and tell the user the expected completion time. Then decide
where to place the resulting data. The planner should slow down or
pause/stop existing work if the new work has sufficiently high priority.
The planner should be able to explain its decisions and recommendations
to the users.*

Users are given performance predictions for their jobs before they
submit them, with alternatives spelled out for them so that they can
make prudent cost-delay-benefit decisions. *[elaborate]{.mark}*

Unified, off-the-shelf component/toolkit solutions are created in common
across all four experiments; the results are usable by future
experiments with relative ease, and change the way science will be done
in the future. *[elaborate]{.mark}*

Scientists request data and/or computations using powerful job
description languages, with a high degree of interoperability with
visual tools. The right balance of visual and textual tool usage is made
possible through well-designed architectures. These languages help
expose parallelism, fault recovery, and data dependencies and
derivations and enhance the location-independence of job specifications.
*[elaborate]{.mark}*

[The critical research breakthroughs needed for this are:]{.mark}

[- virtual data paradigm and supporting catalog and glue
language]{.mark}

[- planning and scheduling]{.mark}

[- ubiquitous and reliable cataloging]{.mark}

[The critical connection factors are:]{.mark}

[- integration languages]{.mark}

[- thorugh analysis and extraction of data processing and data
dependencies]{.mark}

[- reliable and supported tools that can be adopted]{.mark}

[- tools that empower the experiment's software developers rather than
restrict them]{.mark}

# Whats New Here?

[This section to be developed...]{.mark}

GriPhyN's success depends on achieving two fundamental breakthroughs in
computer science research. Our premises are:

1\) that we can develop a paradigm, framework, and representation for
the complex dependencies between science data objects, and can
efficiently and with high integrity capture and accurately replay with
high fidelity the steps needed to re-derive data.

2\) that we can abstract and automate the highly complex and
policy-driven decision making processes to automatically schedule work
in a complex grid of loosely coordinated resource pools without central
ownership.

## The CS Research Program

The computer science research program that we are addressing to achieve
these capabilities is being conducted at the following institutions and
in the following areas:

UCB:CS and LBL: Database query processing research; Request management;
Tertiary storage management; simuation

U of C San Diego: Fault tolerance; [Metadata management; Storage
Resource Management (SRB)]{.mark}

U Chicago: Virtual Data cataloging and processing; domain knowledge
representation; policy research; robust sidtsributed scalable cataloging
service architectures; simulation

Indiana U: User management; Science Portals; portal-to-grid interface
language; ([iGOC]{.mark}?)

Northwestern U: Performance data collectiona and analysis and
predication; monitoring

U S C ISI: Virtual Data cataloging and processing; Planner algorithms;
Fault Tolerance; robust sidtsributed scalable cataloging service
architectures

UW: Job description language and scheduling algorithms and frameworks
(Condor, ClassAds, Matchmaking, DAGMan); storage appliance and
integration of data movement into job descriptions and processing;
recovery of data transfer (NeST and Kangaroo)

Collaborations currently taking place within the teams above include:

Virtual Data cataloging and processing (UC & ISI)

Robust distributed scalable cataloging service architectures (UC & ISI)

Fault Tolerance (UCSD and ISI)

Virtual Data Grid Simulation: (UC and LBL)

The specific topics are:

> [Scheduling / planning / execution management\
> - Superschedulers\
> - Loosely coordinated scheduler interaction\
> - Resource assessment by both monitoring and by planning knowledge\
> - Policy negotiation and arbitration between non-cooperating
> organizations]{.mark}
>
> [Monitoring, execution profiling, and information recording]{.mark}
>
> [Languages and protocols for component integration -- eg: VDL DAGman
> (JCL II)]{.mark}
>
> [CAS and Policy]{.mark}
>
> [Knowledge representation langauges]{.mark}
>
> [Fault tolerance and recovery]{.mark}
>
> [Replica Location Services / ubiquitously available virtual data
> catalogs]{.mark}
>
> [Unified tracking for data objects across storage paradigms. {who to
> do} synergy with the data warehousing paradigm]{.mark}
>
> [Storage management protocols]{.mark}
>
> [Portals; Active notebook.]{.mark}
>
> [CS research problems in the areas of simulation:]{.mark}
>
> [Object clustering from a derived point of view]{.mark}
>
> [Scheduling -- will "throw it at the wall and see what sticks"
> work?]{.mark}
>
> [Testing of different scheduling algorithms]{.mark}
>
> [Generation of synthetic workloads]{.mark}

As can be seen from this list, GriPhyN will provide an extremely rich
and fertile ground for the selection of a large number of doctoral-level
thesis topics.

## The hard issues

[- likely to require some additoinal structure and rigor in the way that
data is processed and derived -- need to make this have high value to
experiments to gain adoption]{.mark}

[algorithmic complexity of the resource scheduling problem]{.mark}

[conistency and availability and manageability of thedatabase structures
involved in tracking]{.mark}

[scaling up to the storage management and datatransfer
capabilities]{.mark}

[ease of use]{.mark}

# Core Technology Milestones

The following list, organized by technology area, describes the major
milestones in the project for addressing the key technology deliverables
that will then be packaged into the VDT and made available for
integration into the experiments.

The details of the integration and deployment efforts are described in
the detailed projectplans being developed by GriPhyN sub-teams working
directly with the experiments. (The year-2 plans for these efforts are
now available in separate documents posted at
[www.griphyn.org/plans]{.mark}).

## Virtual Data

*Year 1*

-   Develop basic information model to represent data elements, the
    relationships between different data types and the characteristics
    of data elements. Develop protocols for storing, discovering and
    retrieving these models. Design and develop tools for creating,
    accessing and manipulating these models by interactive tools, and
    planning and scheduling tools.

> *[Status]{.mark}*: accomplished; demonstrated at SC2001

-   Deploy centralized metadata and replica catalog services. Develop
    tools for managing catalogs.

> *Status*: All four experiments have progressed with their own metadata
> databases. ATLAS and CMS (via the EUDG) have deployed the Globus
> replica catalog in their testbed. GDMP, used within that testbed, is
> based on this catalog implemenation.

*Year 2*

-   Develop techniques for representing data transformations, and
    integrate these techniques into the information model. Develop
    methods and catalogs for categorizing and curating code elements.

> *Status*: Virtual Data Catalog version 0, and a corresponding
> manipulation language, Virtual Data Language 0, was developed and
> demonstrated at SC2001. The design for VDC/VDL1, a candidate for VDT
> release 2.0, is scheduled to begin in Jan 2002.

-   Extend catalog services to support distributed and replicated
    catalogs. Develop techniques for failure detection and fail-over in
    the situation of catalog failure.

> *Status*: A design for a robust and scalable distributed catalog (the
> Replica Location Service) has been designed and documented, and is
> circulating for review among the GriPhyN (Globus) and EUDG teams.
> Prototyping of that design has begun.

*Year 3*

-   Extend information model to support multiple versions of both data
    dependencies and data transformation components. Also extend
    catalogs to support interfaces to request planning and request
    execution modules.

-   Develop distributed algorithms for discovery of information across
    distributed virtual data catalogs.

*Year 4*

-   Augment the information model to include information about
    alternative implementation of data transforms with alternative
    performance characteristics.

-   Develop methods for collecting historical performance information
    and incorporate into the catalogs.

*Year 5*

-   Augment information model to incorporate local and global policy
    constraints.

## Request Planning

*Year 1*

-   Develop generic models for representing execution plans. Define a
    set of API and tools for constructing, traversing, and manipulating
    plan data structures. Develop protocols and formats for storing and
    exchanging execution plans.

> Status:

-   Develop uniform policy representation for code, data and resource
    access. Develop a set of global and local policy scenarios that
    reflect the requirements of the user communities of the four physics
    experiments.

> Status:

-   Develop simple optimization heuristics. Initial thrust will be on
    data movement only and focus on the use of alternative, or branching
    plans to compensate for both resource failure and changes in
    resource performance. Implement planning heuristics in prototype
    planning module. Evaluate performance of alternatives with
    simulation and model based studies, as well as execution on GriPhyn
    testbed.

> Status:

*Year 2*

-   Design a basic planning API, to facilitate access to remote planning
    services from high-level tools without dependence on underlying
    planning heuristics or planning methods. Define and implement
    planning toolkit, providing access to catalogs as well as remote
    planning servers.

> Status: not started

-   Extend planning toolkit to incorporate global and local policy
    considerations into policy construction. Initial focus will be on
    the application of matchmaking as a means method for the
    introduction of policy.

> Status: not started

-   Extend optimization heuristics to include computational resources
    and data transformations (i.e., code). Evaluate the use of
    alternative plans to meet optimization goals.

> Status: not started

*Year 3*

-   Extend request planning APIs and toolkit to support incremental plan
    generation and dynamic replanning. This extended interface will be
    used to couple the request planner with the request execution
    services.

-   Extend the range of planning algorithms to incorporate alternative
    optimization heuristics, for example including factors such cost.

-   Investigate the hierarchal and distributed planning algorithms and
    evaluate their impact on scalability, reliability, and the ability
    to share plans across multiple, independent requests.

*Year 4*

-   Develop algorithms that incorporate policy constraints into request
    planning process. These algorithms just examine the constraints
    applied to each element of the request being planned, and respect
    the constraints for each local resource as well as for the entire
    request, with respect to global policies. Initial focus will be on
    static, non-incremental planning.

*Year 5*

-   Extend policy sensitive optimization algorithms to incorporate
    incremental planning. Develop hybrid strategies that combine static
    and incremental planning. Evaluate performance of new planning
    algorithms both in simulations and on testbed.

## Request Execution

*Year 1*

-   Develop and evaluate a task control language capable of capturing
    the requirements, preferences and dependencies of a PVDG request.
    Implement prototype of an interpreter to a basic subset of the
    language.

```{=html}
<!-- -->
```
-   Enhance the \"Gang Matching\" capabilities of the ClassAd language
    and add these enhancements to the run-time support library.

```{=html}
<!-- -->
```
-   Explore ways to enhance the ClassAd language to support events and
    triggers.

```{=html}
<!-- -->
```
-   Develop a protocol for information exchange between the execution
    and planning agents.

*Year 2*

-   Develop an execution agent capable of receiving a simple plan from
    the planner and interacting with the PVDG services and resources in
    order to carryout the plan.

```{=html}
<!-- -->
```
-   Develop a protocol for the exchange of co-allocation information
    (availability, policy, statistics, ...) between the planner and the
    co-allocation agents.

-   Develop a basic portable and configurable event and trigger manager.

> *Status*: being explored by the joint PPDG-GriPhyN Monitoring working
> group.

-   Develop a framework for gathering statistics on the resource
    consumption profile of completed and in-progress requests and the
    availability of resources.

> *Status*: being explored by the joint PPDG-GriPhyN Monitoring working
> group.

*Year 3*

-   Develop a fault-tolerant version of the execution agent.

> *Status*: research in progress at UCSD.

-   Develop a basic recoverable co-allocation agent. The agent will
    support basic reservation services.

-   Add fault-tolerance to the manager and reliability to basic
    propagation protocols.

```{=html}
<!-- -->
```
-   Develop a fault-tolerant and persistent repository of PVDG
    statistics

*Year 4*

-   Develop a distributed (mobile) version of the execution agent and
    enhance the ability of the agent to adapt to changes in the
    availability, location and capabilities of the grid resources.

```{=html}
<!-- -->
```
-   Interface co-allocation agents with planning agents.

-   Develop reliable, efficient and secure event propagation and
    notification protocols

-   Develop and implement dynamic and incremental execution algorithms

*Year 5*

-   Evaluate the performance of different execution policies.

-   Evaluate co-allocation and reservation policies.

-   Add real-time services to the event and trigger system.

-   Evaluate impact of incremental and dynamic planning on request
    execution.

# Project Participants and Structure

## Project Personnel

Table 1 shows the allocation of graduate students, postdocs, and staff
to the various elements of the project. In the initial budget
allocation, the institutions with larger allocations have some ramp up
in the first year; some CS institutions do not receive funding for
graduate students in the fifth year. We emphasize that while we show a
scenario for approximately constant level of effort at each institution,
we do not expect that we will stick to a static budget for a five-year
project. The management structure outlined in the proposal will work to
optimize the use of resources during the project period.

We anticipate funded personnel being mapped to activities roughly as
follows: \[to update\]

-   CS research will involve 9 graduate students, and 4 postdoctoral
    associates.

-   Virtual Data Grid Toolkit development will involve 3 graduate
    students, and 4 technical staff.

-   Discipline applications will involve 2 graduate students and 6
    postdocs.

-   Outreach and education involves one dedicated staff member.

[]{.mark}

Table 1: Personnel per project and institution, categorized as Graduate
students, Postdoc, or Staff.

  --------------------- ------------ ------------ ----------- ----------- ------- ------- --------------- ------- ------- --------- ------- --------- ---------- ------- --------- ---------- ------- -------
  **Inst.**             **CS                                  **VDT**                     **Physics                                                                                                   
                        Research**                                                        Experiments**                                                                                               

                                                                                          **ATLAS**                       **CMS**                     **LIGO**                     **SDSS**           

                        **G**        **P**        **S**       **G**       **P**   **S**   **G**           **P**   **S**   **G**     **P**   **S**     **G**      **P**   **S**     **G**      **P**   **S**

  **Caltech**                                                                                                                       1       0.5                          0.5                          

  **IU**                                                                                  2               1                                                                                           

  **JHU**                                                                                                                                                                          1          1       

  **NWU**                            1                                                                                                                                                                

  **UC**                1            1            \*          1                   2\*                                                                                                                 

  **UCB**[^1]           3                         \*                                                                                                                                                  

  **UCSD**              2                         \*                                                                                                                                                  

  **[UF]{.mark}**[^2]   []{.mark}    [1]{.mark}   []{.mark}   []{.mark}                                                             1                                                                 

  **USC**                            1            \*          1                                                                                                                                       

  **UTB**                                                                                                                                                        1[^3]                                

  **UW-Mad**            3                         \*          1                   2\*                                                                                                                 

  **UW-Mil**                                                                                                                                                             1[^4]                        

  **Total**             **9**        **4**                    **3**               **4**   **2**           **1**                     **2**   **0.5**              **1**   **1.5**   **1**      **1**   
  --------------------- ------------ ------------ ----------- ----------- ------- ------- --------------- ------- ------- --------- ------- --------- ---------- ------- --------- ---------- ------- -------

[This is based on the original proposal; we need to update to reflect
final budgets. Can everyone please check?]{.mark}

[Other cost sharing needs to be included: e.g., GR at UW?? What else?
IU?]{.mark}

Note that some of the larger budgets were somewhat reduced in the first
year. A \* denotes summer salary for faculty.

## Faculty

The following is a list of the faculty involved in the project:
[VERIFY]{.mark}

-   [CS research: Arpacci-Duseau, Foster, Franklin, Kesselman, Livny,
    Marzullo, Moore, Schopf, Taylor]{.mark}

-   [VDT development: Ian Foster, Carl Kesselman, Miron Livny]{.mark}

-   [ATLAS: Gardner, Huth]{.mark}

-   [CMS: Avery, Bunn, Newman]{.mark}

-   [LIGO: Allen, Lazzarini, Campanelli, Romano]{.mark}

-   [SDSS: Szalay]{.mark}

## Project Team Structure

[The following text is taken from the proposal, modified only to reflect
the addition of CS personnel at NWU and the removal of CS personnel at
UF.]{.mark}

"We structure our research project as three distinct but tightly
integrated activities:

-   ***IT research***: groundbreaking IT research motivated and guided
    by challenges encountered by domain scientists in meeting their
    computational and data management needs.

-   ***Application experiments***: prototyping new information
    technology and interfacing it with scientific applications in
    real-life test-bed environments defined by CMS, ATLAS, LIGO, and
    SDSS requirements.

-   ***Tool development***: turn "winning" prototypes into production
    quality tools to be used by the scientific community.

The 26 researchers---12 computer scientists and 14 experimental
physicists---that we have brought together to attack these problems have
been intrigued by the research challenges, the possible impact, and the
scope of this project. These researchers represent a wide inter- *and*
intra-disciplinary spectrum of research interests, talent, and
experience. The computer scientists are organized in seven
groups---Berkeley, Chicago, Indiana, NWU, San Diego, USC, and UW
Madison---each managed by local GriPhyN personnel and each contributing
a unique capability to the project and responsible for one major
research activity. The physicists are distributed across a comparable
number of institutions, chosen with a view to IT expertise and
connections with the physics experiments.

The rich collection of technology and software already developed by
project participants means that we can start all three of the phases
just listed in parallel. The result will be a steady stream of IT
research results, application experiences, and production quality
software.

We plan to coordinate these diverse efforts via the definition and
frequent review of a *PVDG architecture* that defines the interfaces
between key components, and the scheduling of frequent *integration
events* in which components developed by different groups are brought
together for interoperability testing."

# Project Process Relationships

Although the complex worlds of the four GriPhyN experiments defy common
and uniform solutions, we nonetheless propose to base the GriPhyN
activities within each experiment on a similar planning approach, based
on 1-year cycles. This section describes this common, and how the
experiment activities interplay with CS research and toolkit
development.

This yearly goal-oriented approach will fit well with cyclic events such
as project reviews and the demo-driving Supercomputing conference; it
may require adjustments, however, in order to accomplish integrations of
deliverables into experiment plans that are each driven by a
project-specific calendar.

[The activities in more detail are:]{.mark}

> [Analysis\
> CS research\
> which requires: Research Testbed Development\
> and which results in: VDT development\
> Integration\
> which requires: Deployment Testbed development\
> Evaluation\
> Education and Outreach]{.mark}

The figure below describes an idealized one-year activity plan for the
overall project; for each remaining year we would presumably follow a
similar pattern (at least, at this point in our planning). CS activities
are shaded dark, experiment activities light. The activities nearer the
top of the figure feed the activities lower down, with the challenge
problem solutions representing the ultimate GriPhyN goals. A very
important aspect of our coordination plan is that the CS activities
*span across experiments*, striving to conduct research and create tools
that that fit the needs of *all* of the experiments.

![](media/image2.wmf){width="6.493055555555555in"
height="3.0590277777777777in"}

*Figure 1: Common Yearly Plan for Experiment Activities.*

The yearly plan predicts about 2-3 VDT point releases per year (based on
a VDT major-release plan described in Section 3), continuous CS research
and application analysis (the latter at a steady but less intensive
rate), and one cycle of challenge problem identification, development,
and integration. As appropriate, the challenge problem cycle can be
repeated several times per year, possibly in an overlapped fashion,
depending on the nature of the chosen problems and available integration
opportunities that are driven by experiment needs and schedules. This
plan reflects the project interaction model that was described in the
original proposal, shown in figure 2, below.

The main activities of this common planning approach are outlined in the
following sections.

![](media/image3.wmf){width="5.129861111111111in"
height="2.392361111111111in"}

Figure 2: Process and information flow within the GriPhyN project.

Describe seed planting paradigm: vdl; measurements;

## Application analysis

*[Shorten this section- don't over commit to too much]{.mark}*

The purpose of application analysis is to determine what processes in
each experiment could benefit from the type of results that GriPhyN
seeks to produce, to refine the requirements for GriPhyN research,
development, and deliverables, and to figure out how to apply the
results back into the experiment. *This activity is critical to the
relevance and utility of GriPhyN results to the experiments.*

Unfortunately, this activity has also proved to be difficult to conduct,
and has not *yet* yielded the necessary information back into the
project. Difficulties include: much of the information is not yet known,
and needs to be extrapolated from past experience; experiment
architectures, applications, and decisions are still being formed; the
information involved is heavily distributed and the project documents
and information sources in which requirements are embedded are usually
voluminous. On the other hand, the LHC experiments have been very
successful at modeling the expected processing flows within their
applications, so there is a positive basis for hope here. We propose to
re-assess the process and to find an approach that works and delivers
the expected benefits to the project.

Another goal of application analysis is to compare requirements of the
four experiments, and then identify common needs that can be met with
common tools, architectures, paradigms, testbeds, and infrastructure. If
the mechanisms that GriPhyN seeks to create need to be heavily
customized for each experiment, then our work is likely to be of less
value to other scientific efforts than if we can demonstrate that our
results have proven themselves in the four participating experiments.

Stated in an over-simplified manner, the key question we need to analyze
is this: how do the experiment's scientists process data? The
information we need to capture includes:

\- dataset types stored (both types of files and types/classes of object
collections)\
- definition of jobs and job types, what their control parameters are,
and how they are expressed and invoked\
- the grouping of jobs into processing pipelines that may be internally
amenable to virtualization\
- derivation dependencies for each dataset type (the sequence of
transformations to create each dataset type)\
- the frequency and priority of each data object, program, and
information process\
- with what mechanisms and frequency will jobs look up and locate data
copies to use\
- the location of the storage of each dataset type in a virtual
organization (e.g., what tier / location the data resides at)\
- the likely replication patterns of the datasets (where to, for how
long, how/if replicas are eventually disposed of)

To begin with, it will be useful to create a high-level, abstract model
of experiment data flow, to use as a guide to the data flow analysis.
For example, it seems that at a very high level, most of our experiments
follow a model that is something like:

*Capture* and/or simulate\
*Refine* the raw or simulated date into a more manipulatable form\
*Re-factor* and/or reorganize the data, sometimes changing the
dimensions upon which its based\
*Index* the refined data, gradually building knowledge about the science
phenomena inherent in the data\
*Distribute* the data within the virtual organization for local
processing\
*Analyze* the data, typically through search, filtering, and statistical
correlation techniques\
*Reprocess* previous steps, backtracking as necessary, as algorithms,
indexing, and search criteria are refined

We proposed to develop a common format for describing these processes,
data flows and dependencies. We need to look for new ways to describe
the changing rates of data production and consumption within each
experiment, and to describe the manner in which data items depend on and
are derived from each other. A good example of the beginnings of such an
effort are represented in the documents that Koen Holtman has produced
to describe the CMS experiment \[references\].

We see the analysis effort proceeding in 2 phases: Step 1 is to locate
the best possible source information and make it broadly available to
all GriPhyN by maintaining reference web pages that link to appropriate
experiment activity pages. Step 2 is to analyze that information, and
reduce it, and then extract the information from those sources into a
common GriPhyN format.

Ideally, we will identify common information about each experiment in a
common format using a common vocabulary. We need to determine the
aspects of each experiment's data processing processes that are most
relevant to GriPhyN's mission.

The following knowledge bases are proposed, to document the analysis.
This information should be maintained as a continually updated GriPhyN
document set:

-   Data and Application Map -- a chart showing data types, application
    tools, and their dependencies at a glance. By "data types" we mean:
    file types, object classes within persistent object-oriented
    databases, and tables within relational databases.

-   Data dictionary -- a detailed description of each data type, down to
    the level where computer scientists can see and understand the
    access patterns and the derivation dependencies of that data.

-   Tool dictionary -- a detailed description of each relevant
    application that will be part of Grid jobs and/or data
    "transformations". We need to, in particular, understand these
    applications from a data transformation and data dependency point of
    view. What data objects are searched or read by the application, and
    what data objects are produced or transformed by the application? We
    also need to understand in detail how parameters and input/output
    specifications are passed to applications, and how some applications
    dynamically navigate around a massive information base.

-   Data requirements spreadsheet -- a summary of quantitative data
    storage and transfer requirements, detailing a time-varying
    birds-eye view over multi-year periods of how data will be produced,
    consumed, and replicated throughout the multiple sites and tiers of
    each experiment's virtual organization. This data will be used
    primarily to determine the scaling needs for data transport and
    cataloging mechanisms, in terms of storage capacity, catalog
    capacity, and transaction rates.

Much of this knowledge base should consist of consise,
reference-manual-style documentation that details specific data formats,
tools, and science-driven IT processes. We want to collect and tabulate
a useful reference base of information, rather than a lot of words.
Where possible, this reference base should consist of pointers to the
experiments' document repositories.

[\[Ref to Koen's documents here\]]{.mark}

## Infrastructure (testbed) construction

[\<Locate text that describes levels of testbed and insert
here\>]{.mark}

[Key Q is how to describe ivdgl here]{.mark}

The computing infrastructure of GriPhyN will involve three levels of
Grid resources:

*Research testbeds*: small grids where software or application research
can be conducted and tools developed\
*Experiment testbeds*: larger grids where the viability of challenge
problem solutions can be demonstrated\
*Production resources*: where challenge problem solutions can be placed
in live (production) use by the experiments.

The current vision is that these resources will be unified into a single
"GriPhyN Grid" to provide uniform access to and control of these
resources as needed by the project. Currently, we expect this grid to
contain some mix of research, challenge problem, and a limited amount of
production testbeds within it. (We defined a "testbed" as a set of nodes
within the Grid). This Grid will:

\- run successive releases of the VDT\
- be available to all GriPhyN project members for research, development,
and challenge problem work\
- be under the control of a single Certification Authority\
- have a well-maintained Grid Information Service\
- contain an agreed-upon mix of job execution facilities\
- contain other shared infrastructure such as test and production
replica location services and data transfer services

The experiment-maintained testbeds (for example, the ATLAS testbed)
would be used mainly in the challenge-problem development and
demonstration phases of the project, and the construction and management
of those testbeds could be handled by the experiments and related
projects (such as PPDG in the case of ATLAS and CMS).

Most of the final stage of GriPhyN solution development -- live
deployment -- is expected to take place on the experiment's production
resources, but we expect that there may be cases where some types of
live deployment can take place on GriPhyN grids (for example, running
preliminary analyses where the experiment does not require complete
control of the execution environment.

Compatibility issues: if challenge problems are developed using a
specific VDT toolset, it's important that deployment take place on an
identical or compatible base. Due to the complexity of the tools (both
grid and application) involved, its very difficult to ensure that
GriPhyN-developed solutions will run correctly if the target environment
is not precisely matched to the development environment.

The infrastructure tasks will typically include:

\- Identification of resources (hosts,...)\
- Design of Login administration mechanism and certification mechanism\
- Installation of application software\
- Installation of VDT\
- Creation of VO's\
- Establishment of CAS's and policies (policy design a major task)\
- types of work\
- types of user groups\
- priorities of access to resources: computing, storage, network\
- Design and setup of Catalog architectures\
- Namespace management

It seems clear at this point that the computing resources from which the
GriPhyN grid will be constructed will not be contributed unofrmly from
each project institution. Currently, it appears that resources to
construct this grid might be available from UW, UFL, UTB, and ANL.

Once the basic infrastructure is in place for both production and
research, the level of infrastructure effort should diminish somewhat,
and involved mainly the installation of new releases of the VDT.

In our process diagram (figure 1), infrastructure deployment is shown
keyed to the availability of new toolkit releases; note that it could
also be triggered by the availability of new hardware resources that
could be integrated into the GriPhyN testbed.

Note that an excellent challenge problem for all experiments is to
develop policy-based resource sharing mechanisms that make any
under-utilized resources of each experiment's testbeds and processing
farms available to the other experiments in a dynamic, on-demand basis.

*Open Issue*: we need to clarify exactly how the infrastructure building
effort will be related to and coordinated with iVDGL.

## VDT Development

***[Fit into below:]{.mark}***

***[Planner levels]{.mark}***

***[M&M (Any idea of scheduling)]{.mark}***

***[KR language tools]{.mark}***

***[RLS]{.mark}***

***[Gripe? Integ with other efforts from UK?]{.mark}***

***[Relational support]{.mark}***

***[OO support]{.mark}***

Point releases of 2.0 before end of PY2

One major release every project year

Features introduced in each PY through point releases

*[Need to clean up the merged feature lists in this section]{.mark}*

The following release plan summarizes our initial vision of the main
features delivered each year. Note that this integration and deployment
activity tracks the principal features listed in the research areas
above. *Also note that this schedule of feature rollouts is still
subject to change, based on the availability of underlying technology
and the needs of experiment deployments and and integration.*

**VDT-1 (Basic Grid Services)** provides an *initial set of grid
enabling services and tools*, including security, information, metadata,
CPU scheduling, and data transport. VDT-1 will support efficient
operation on O(10 TB) datasets, O(100) CPUs, and O(100 MB/s) wide area
networks and will build extensively on existing technology.

*Now scheduled for 1Q 2002.*

*Instructions or script for installing a specific recent Condor release
(including Condor-G and DAGMan).*

6.3.1 release supported by the Condor Team.

DAGMan

Globus 2.0

GDMP

*Configuration scripts for replica catalog, GridFTP, GDMP, and MDS that
are specific to the GriPhyn/iVDGL test grid.*

*Exploring an off-the-shelf installer (such as PACMan, RPM, etc).*

**VDT-2 (Centralized Virtual Data Services)** provides a *first set of
virtual data services and tools*, including support for a centralized
virtual data catalog, centralized request estimation, centralized
request planning, network caching, and a simple suite of distributed
execution mechanisms. Representation and exchange of local policies will
be supported for network caches.

Potentially includes:

Virtual Data Catalog structures and VDL engine

VDL and rudimentary centralized planner / executor\
Community Auth Server

**VDT-3 (Distributed Virtual Data Services)** supports *decentralized
and fault tolerant execution and management* of virtual data grid
operation, via integration of distributed execution mechanisms able to
select alternatives in the event of faults, agent-based estimation and
monitoring mechanisms, and iterative request planning methods. This
version will support O(100) TB datasets, O(10 TB) network caches,
O(1000) CPUs, and O(400 MB/s) networks.

A major release, depending on new functionality from Globus, Condor, and
other sources.

Potentially includes:

Reliable File Transfer service\
Striped GridFTP service\
Managed storage element (NeST-based?)\
Policy based planner\
Distributed high-capacity catalogs (based on Replica Location Service)\
Virtual data generation semantics\
Basic fault tolerance\
Metadata integration

**VDT-4 (Scalable Virtual Data Services)** *scales virtual data grid
operation to realistic magnitudes*, supporting applications involving
widely distributed O(1 PB) datasets, O(100 TB) network caches, and
O(10,000) CPUs.

Potentially includes:

Distributed planner\
fuzzy virtual data description mechanisms\
advanced fault recovery

**VDT-5 (Enhanced Services)** enhances VDT functionality and performance
as a result of application experiences.

The final project software deliverable. Provides an enhanced and stable
VDT base and is packaged for general use outside GriPhyN, in particular
for use by other scientific disciplines.

## Challenge Problem Identification

We propose to conduct all integration of GriPhyN results into the
experiments through the vehicle of *challenge problems*. This phrase is
appropriate, in that we view this integration as the *most challenging*
aspect of the entire GriPhyN program. Our partner experiments are large
and complex: scientifically, technically, logistically, and
organizationally. Challenge problems serve as a focal point of our
efforts. They give the plan a concrete grounding, help identify
integration points within experiments' processes, and provide
demonstrable results of clear value.

Challenge problem solutions involve integrating VDT components with
application code and tools to yield working solutions that *are suitable
for* live experiment usage. Examples of challenge problems and CP
sequences that are created from the GriPhyN feature sets include:

CP-1 Virtualize an application pipeline\
CP-2 High speed data transfer to replicate results\
CP-3 Automated planning\
CP-4 Mixed replication and re-materialization at high speeds\
CP-5 Abstract generator functions added to virtualization\
CP-6 Jobs submitted from high-level tools/UIs (e.g., GRAPPA)\
 CP-7     Higher level Intelligent job management: Transparency, Fault
Tolerance, Advanced policy and scheduling?  Monitoring and information
synthesis (*from Ruth*)

It is not easy for an orthogonal research program to insert its results
into the mainstream of independent experiments, with independent
schedules and, in many cases, funding and oversight. This is further
complicated by the GriPhyN mandate to find common solutions across the
experiments which runs counter to the need typically felt by each
experiment for precisely tailored custom solutions to their complex
software problems. The need for commonality is dictated in part by
limited staff resources, but primarily by the need to produce results
which can benefit numerous disciplines.

We will apply an "intercept" strategy to challenge problem design: we
need to determine where the experiments will be when the GriPhyN results
are expected to be ready for live usage; otherwise, the results will be
irrelevant to the experiments. This will require that we identify
integration points (both functionally and in the experiment's schedule),
negotiate the willingness of the experiments to accept and perform
integrations, achieve timely deliverables, and track the experiments and
their commitments to GriPhyn, so that we can adjust the GriPhyN plans to
accommodate any changes that occur in the experiment's plans.

In designing challenge problems, we need to clearly document the value
proposition that the GriPhyN research results would bring to each
experiment. In some cases, we will need to make a tradeoff between value
to the experiment, difficulty of the challenge, and risk to the
experiment for integrating a GriPhyN result. We need to be keenly aware
of the quality assurance processes of the experiments if we are to
propose integrating changes into mainstream tools upon which the
experiments are critically dependent.

[(insert value proposition list for virtual data here -- good list is in
some earlier notes)]{.mark}

As part of the challenge problem identification, we need to develop a
plan for how the solution to the problem will (or can) be ultimately
integrated back into the experiments standard science processes.

## Challenge problem solution

[Drop this section or incorporate into above.]{.mark}

Demonstration/proof-of-concept phase

[*Reword:* Being able to create a compelling demonstration of the
application of GriPhyN research is perhaps the single most important
phase of the entire program. This is a good thing, because for most of
us its also the most exciting and rewarding phase: proving that we can
apply our research to the solution of practical problems.]{.mark}

## Challenge Solution Integration

[QA cycles; test processes; resources (people, machines, and data) to
execute tests.]{.mark}

[Define the transition of support from GriPhyN staff to the staff of the
experiment.]{.mark}

## Requirement Differences between Projects

The following factors may dictate differences between the 4 experiments'
plans and require deviations from the common experiment activity
template shown above:

Timelines; availability of and development schedules for new tools.\
Technology bases (database and data storage technology; languages and
compilers; application frameworks)\
Object model differences\
Science-driven data processing differences\
Inter-grid-project dependency differences (eg, ATLAS and CMS influenced
by both PPDG and EDG)\
Coordination w/ other science projects:\
LIGO-VIRGO\
SDSS-NVO, (LSSC?)

# Coordination Between Grid Projects

[accepting /adopting components and contributions from other projects
e.g. GDMP from PPDG/EDG. (section suggested by Ruth...)]{.mark}

**PPDG**

*Expect from PPDG*: GDMP; Scalability feedback and testing of
distributed catalog solutions and high-end databases for catalogs;
research into mechanisms for distributed physica analysis (Conrad
Steenberg); research into fault tolerance (Takako Hickey)

*Provides to PPDG*: VDT, [??? more]{.mark}

*Shares with PPDG*: DGA; analysis of CMS data management requirements

**iVDGL**

*Expect from iVDGL*: acquisition and setup of hardware for testbeds;
uniform installation of VDT

Provides to iVDGL: VDT; maybe components (beyond VDT) for construction
of iGOC (open issue)

Shares with iVDGL:

**EUDG**

Expect from EUDG: GDMP (via PPDG); Scalability feedback and testing of
distributed catalog solutions and high-end databases for catalogs

Provides to EUDG: VDT

Shares with EUDG: development effort for datagrid components (RLS, RFT,
RRT); conventions for toolkit installation;

*WPx -- apps -- connection through FNAL; looking at BOSS, etc?*

*WPx - scheduler*

**NMI / GRIDS Center**

Expect from NMI / GRIDS Center: basic packaging of Globus and Condor to
serve as base for VDT; support services to GriPhyN user community for
VDT

Provides to NMI / GRIDS Center: VDT

Shares with NMI / GRIDS Center:

**JTB & Co.**

Expect from JTB:

Provides to JTB:

Shares with JTB:

GGF

Expect from GGF:

Provides to GGF:

Shares with GGF:

**Globus Project *™***

Expect from Globus: All services of Globus 2.0 (GSI, MDS, GRAM, Replica
catalog and management; GrdFTP); RLS; RFT (to be developed with funding
from DOE SciDAC and PPDG);

Provides to Globus: Requirements and requirement analysis; simulation
results; monitoring tools

Shares with Globus: monitoring requirements, techniques, and tools for
eventual incorporation into and support by Globus

**DTF**

Expect from DTF: Detailed specification of environment: Chips,
compilers, OS, and data storage and transfer architecture; job execution
and scheduling environment

Provides to DTF: GriPhyN needs to arrange with experiments the porting
anc certification of some portion of their applications to the specific
IA64 chip and platform needed to run the in DTF. Potentially,an
NMI-compatible version of the VDT to augment the base Grid software on
DTF nodes.

Shares with DTF:

## Coordination Regarding Virtual Data Toolkit

This work will be done in collaboration with the GRIDS Center and the
NCSA Alliance, and will integrate software from other DOE-and NSF-funded
Globus and Condor development activities. We envision this work
providing the base software installation for the iVDGL.

The GriPhyN contributions to this work will be as follows:

-   Addition of various components, over time (e.g., in the first year,
    DAGMan)

-   Definition of a standard software release, consistent with the Data
    Grid Reference Architecture (DGRA).

-   In collaboration with the GRIDS Center, packaging, integration, and
    documentation to produce an easily installable, documented binary
    version of this software release.

-   In collaboration with the GRIDS Center, provide support for the
    software.

We assume that the iVDGL will handle:

-   Operation of central services for GriPhyN experiments that wish to
    use this.

-   Deployment of software on resources to construct testbeds.

-   Development of push mechanism for automatic distribution of updates.

# Project Logistics

In this section we described project plans for Reporting,
Communications, and Meetings.

## Coordination Meetings

We hold the following types of meetings:

-   All-hands meeting: twice a year. Plans are presented here, people
    report on progress, etc.

-   Periodic applications-software meetings to discuss software
    development and iVDGL deployment: twice a year (half-way in-between
    the two all-hands meetings). These provide input to the next round
    of planning.

-   Periodic application-CS one-on-one meetings: structured as an
    "all-hands" on each side. Ideally these are held twice a year, also.

-   Occasional CS research meetings: as needed, on specific topics.

## Communications

We maintain:

-   Various email lists, all archived.

-   A web site, [www.griphyn.org](http://www.griphyn.org/), with news
    etc., a calendar of upcoming events, and an archive of material from
    past events.

-   Analysis and design documents for each experiment, and for elements
    of the VDT architecture.

-   The VDT and associated documents.

-   A Data Grid Pubs web site with relevant publications.

-   Status reports, collated and made available on the GriPhyN web site.

## Planning

We maintain a GriPhyN Project Plan document, revised on a six-monthly
basis prior to each all-hands meeting, and presented at the all-hands
meeting.

## Reporting

We provide NSF with a yearly report once each year, in June.

# [Education and Outreach]{.mark}

The Education/Outreach (E/O) program of the GriPhyN project is designed
primarily to expose faculty and students at other U.S. universities and
institutions to GriPhyN research. In particular, it intends to promote
learning and inclusion via the integration of a diverse set of minority
and under-represented institutions into the scientific program of
participating physics and computer science experiments. This program
will engage all GriPhyN senior personnel, with each committing to
lecturing and mentoring activities at these institutions.

In order to facilitate and coordinate these activities, The University
of Texas at Brownsville recently hired a full-time faculty member,
Manuela Campanelli, to serve as E/O coordinator for GriPhyN, with a
start date of Fall 2001. Her initial plans for E/O are described below:

1\) Web page for GriPhyN E/O:

The E/O web page will grow to contain basic educational material about
data grids and the participating physics experiments. In addition, it
will provide basic technical support information (e.g., documentation,
user manuals, how-to guides, etc.) for the GriPhyN virtual data
toolkits. We also plan to extend a web-site that Alex Szalay (at Johns
Hopkins University) and Jim Gray (at Microsoft) are developing for
accessing SDSS data, to illustrate the concept of virtual data. One idea
is to produce on-the-fly custom data sets representing images of the sky
as viewed in different frequency bands.

The evolving GriPhyN Education an Outreach Web page is available now,
at:

<http://www.aei-potsdam.mpg.de/~manuela/GridWeb/main.html>

and is linked to from the main GriPhyN web page at
[www.griphyn.org](http://www.griphyn.org/).

2\) Research Experience for Undergraduates (REU) supplement:

In Fall 2001, Campanelli plans to submit a proposal to NSF requesting an
REU supplement to support students doing grid-related research.If
funded, students would be able to work on research projects during the
summer months at participating GriPhyN (or iVDGL) institutions. At the
end of the year, the students would present posters or give talks at a
conference specifically designed to showcase their work.(Note: Philip
Dukes, another faculty member at UT Brownsville, who has experience in
physics education, may serve as co-PI on this proposal.)

3\) Grid-enable the UT Brownsville Linux cluster:

UT Brownsville has nearly completed constructing a 96-node
Linux-cluster. Although the cluster will be used primarily for LIGO data
analysis, it can also serve as a testbed for GriPhyN software and be
used to introduce minority students at UT Brownsville to distributed
computing and grid-related technology. If the iVDGL proposal and the REU
supplement get funded, we will be able to support an additional two or
three undergraduate students to learn how to install and run grid
software, like Globus or Condor, on the completed cluster.

4\) Involving other minority serving institutions:

If the iVDGL proposal is funded, two other minority-serving institutions
(Hampton University and Salish Kootenai College) will receive funds for
hardware and personnel to construct small clusters (i.e., Tier3
centers), thus bringing a large number of additional minority students
directly into contact with large-scale grid research. Campanelli will
coordinate the E/O effort for the iVDGL project as well, providing
technical support for the Tier3 centers and functioning as an interface
with the GriPhyN research community. Moreover, Keith Baker, who would be
the lead person for the Hampton University Tier3 center, is a principal
investigator for QuarkNet.

5\) Leveraging on-going existing E/O programs:

There are a number of on-going education and outreach programs that we
plan to utilize in the forthcoming months:

a\) Indiana University and The University of Florida are participating
GriPhyN institutions and active QuarkNet centers. GriPhyN researchers at
these institutions will be encouraged to provide a grid-related
component to the already existing QuarkNet activities.

b\) Valerie Taylor (a GriPhyN senior investigator at Northwestern
University) is a PI for the Coalition to Diversify Computing project
within EOT-PACI\-\--the education, outreach, and training partnership
for advanced computing resources. Campanelli plans to work with Taylor
on ways to link the E/O activities of GriPhyN with the EOT-PACI program.

c\) We have already begun talks with ThinkQuest to develop special
challenge projects based on the application sciences and grid
technology. GriPhyN (or the iVDGL project) would provide resources in
the form of interesting data sets (e.g., SDSS images or LIGO data)
and/or \"sandbox\" CPUs that students could use when creating innovative
web-based educational tools for ThinkQuest competitions.

6\) Course development:

All GriPhyN senior investigators will be encouraged to include grid
concepts in their physics or IT courses. In addition, each GriPhyN
senior investigator is committed to lecturing and mentoring activities
at other (in particular minority serving) institutions. These activities
are important as they are specifically targeted to promote and improve
the education of students regarding grid-related activities.

7\) Workshops and tutorials: Campanelli, together with several other
GriPhyN senior investigators, will organize several \`how to\' workshops
and tutorials at the various Tier3 minority serving institutions. In
order to facilitate the participation of all senior investigators and
given the limited E/O budget, we propose to do this in conjunction with
at least one of the \`All-hands GriPhyN Meetings.\" This would allow a
more direct and larger participation of minority students, without
needing additional travel money for students. UT Brownsville has
volunteered to hold such a meeting in Spring 2003.

8\) Other possibilities:

An interesting possibility for GriPhyN E/O is the creation of an
educational documentary about GriPhyN computational data grids. Because
this project would require significant budgetary and human resources
that are not presently available in our E/O program, we are considering
the possibility of working together with other national or international
grid partners, like the European DataGrid, which has expressed an
explicit interest in this direction. Such a documentary would certainly
produce a worldwide impact on the general public, and could also be used
as a powerful media to reach high-school students and teachers.

[Additional Specific Education/Outreach (E/O) goals for 2001:]{.mark}

1\) Since the E/O program of the GriPhyN and iVDGL projects is designed
to expose faculty and students at other U.S. universities and
institutions to grid-related research, it is extremely important that
all GriPhyN and iVDGL senior personnel be committed to lecturing and
mentoring activities at other institutions.  We will keep a record and
make available a list with materials of talks given about the grid and
GriPhyN.

2\) Our second near term goal is to give undergraduate students the
opportunity to participate in grid-related research at Griphyn/iVDGL
institutions by taking advantage of the NSF Research Experience for
Undergraduate (REU) Program.  [We are going to submit a proposal for an
REU supplement later this fall,]{.mark} but in order to get that
started, we need to know which institutions/faculty are willing to
mentor students during the summer months as part of this program. This
should be submitted to Manuela Campanelli \<manuela@aei-potsdam.mpg.de\>
and/or Joe Romano  \<jromano@utb1.utb.edu\> as soon as possible sending
along a list of possible research projects.

We will seek funds to support 10 to 20 undergraduate students to do
GriPhyN related research at various GriPhyN institutions. Students
themselves will then apply and choose the mentoring institutions on the
basis of the research projects proposed by each institution. This will
already provide some pre-selection process. Further selection should
then be done by the mentor based on the student individual skills
required for the chosen project.

[\-\-\-\-\-\-\-\-\-- old material to integrate or discard appears below
this point in this section \-\-\-\-\-\-\-\-\-\-\-\--]{.mark}

[Specific milestones are as follows:]{.mark}

a.  [\[UTB\] Install VDT software on UTB cluster (Oct 1).]{.mark}

b.  [More ...need to fill in from material from Manuela and Joe.]{.mark}

[Material Provided by Joe]{.mark}

[Q4-FY00:    Begin search for E/O coordinator]{.mark}

[            Begin benchmarking tests for UTB linux cluster]{.mark}

[Q1-FY01:    Search for E/O coordinator continues]{.mark}

[            Benchmarking continues; Order equipment]{.mark}

[            Search completed (M. Campanelli hired)]{.mark}

[Q2-FY01:    Begin construction of UTB linux cluster]{.mark}

[E/O coordinator makes contacts with European data grid projects, other
E/O projects (EOT-PACI, QuarkNet, ThinkQuest), and possible tier3
centers for the iVDGL proposal]{.mark}

[Construction of UTB cluster completed]{.mark}

[Q3-FY01:    Begin installing condor, globus on UTB cluster]{.mark}

[Q4-FY01:    E/O coordinator starts at UTB]{.mark}

[            Prepare and submit proposal for REU supplement for iVDGL
(if]{.mark}

[            funded)]{.mark}

[            Continue grid-enabling UTB cluster]{.mark}

[            Design simple (passive) web-page for GriPhyN E/O
activities]{.mark}

[Q1-FY02:    Begin extension of web-interface to SDSS data to include
concept of virtual data]{.mark}

[Q2-FY02:    Continue work on SDSS web-interface]{.mark}

[Consider incorporating goals re EUDG-IE Gianfranco Mascari, Emanuela
Piervitali]{.mark}

[Into outreach and/or partnership sections]{.mark}

# [Goals]{.mark}

[Items from this section that are still relevant and to be done will be
moved to latter sections.]{.mark}

## [Remainder of Year 1 to September 30, 2001]{.mark}

Our primary goals in Year 1 are to lay the groundwork for the project,
by:

-   Completing initial definition of our virtual data grid architecture,
    and prototyping initial virtual data ideas.

-   Establishing the first version of the VDT, "Basic Grid Services,"
    providing basic security, information, metadata, CPU scheduling, and
    data transport services.

-   Creating a "VDT Canonical Application" that captures key elements of
    virtual data concepts.

-   Defining VDT requirements in each application, and conducting
    proof-of-principle computations to explore these requirements.

-   Establishing research projects aimed at furthering the longer-term
    goals of the project.

-   Laying the groundwork for the education and outreach program.

## Year 2: October 1, 2001 to September 30, 2002

Our primary goals in Year 2 are as follows:

-   Develop a solid set of virtual data software, addressing
    materialization.

-   Have at least two experiments do production computing using VDT 1,
    using distributed resources.

-   Achieve solid results from research projects established in the
    first year, with potential paths for transitioning to production
    software identified.

-   Achieve concrete results from the Education and Outreach program.

(Virtual data) Develop techniques for representing data transformations,
and integrate these techniques into the information model. Develop
methods and catalogs for categorizing and curating code elements.

(Virtual data) Extend catalog services to support distributed and
replicated catalogs. Develop techniques for failure detection and
fail-over in the situation of catalog failure.

(Fault tolerance) Examine the issues of \"consistency\" in the data
replication services and virtual data. there are three kinds of
consistency that have come up so far: (1) replicated metadata; (2)
replicated data (being a grid file service, there is less trust one can
place in repositories); (3) dependency tracking - being able to trace
the effects of an error introduced by an application or filter.

\[UW,UC, LBNL\] Define NeST/Globus/DRM integration with the goal of
producing a managed storage element architecture.

#  {#section .unnumbered}

# Appendix: Cost Sharing Arrangements {#appendix-cost-sharing-arrangements .unnumbered}

[This is the text from the original proposal about cost sharing. We need
to update this and make sure we know what we are supposed to be getting,
in case NSF asks.]{.mark}

Funding for undergraduates is not requested explicitly but will be
obtained from other sources. Additional leverage will come from the
substantial involvement of the experimental groups in establishing and
using prototype systems and from the substantial facilities that will be
used for tests and demonstrations of the technology and tools that
result from GriPhyN. Additional facilities are expected to be
contributed by interested vendors. Several of the participating
institutions will supply matching funds, which are anticipated to
provide at least an additional 5 FTE to the GriPhyN team. At the time of
submission, the following institutions had made financial commitments to
contribute as follows:

-   University of Florida 2 staff, 2 students \$1,170,000

-   Indiana University 90,000 (Proposed)

-   Boston University 1 staff, first year 111,000 (Proposed)

-   U. Wisconsin/Milwaukee 25,000

-   USC/ISI Student tuition 69,739

In addition, proposed in-kind contributions of effort have been received
from Indiana University (staff; computer scientists), from University of
Wisconsin at Madison, University of Florida, and University of Illinois
at Chicago (computer scientists).

Note that Boston University has made this commitment, even though it
will not receive direct funding from GriPhyN**,** because it believes
the results will be important to its scientific work on the ATLAS
detector. The University of Pennsylvania hopes to make a similar
contribution. Discussions are underway at additional institutions which
we anticipate will result in additional matching resources.

Note that in-kind matching support from Indiana University includes
un-funded participation of two computer science senior investigators
(Gannon, Bramley) and participation of University Information Technology
Services (UITS) staff:

Massive Data Storage team

-   10% FTE - Leigh Grundhoefer: storage services R&D, system
    engineering, etc.

-   5% FTE - Gustav Meglicki: storage services R&D, test and evaluation,
    etc.

High Performance Computing team

-   10% FTE - Dan Lauer: high performance computing support

Data Networking team

-   10% FTE - Steve Wallace, Abilene Network Operations Manager (and
    staff): network engineering, performance monitoring, etc.

Video Networking and Collaboration

-   10% FTE - Doug Pearson (and staff): network engineering,
    collaboration support (video, application sharing, etc.)

# Appendix: Risks, Contingencies, Critical Success Factors, Open Issues {#appendix-risks-contingencies-critical-success-factors-open-issues .unnumbered}

*igoc -- where will the technology come from? Need to build it in
GriPhyN? Package in the VDT or in an "iGOCTK" ? Don't want scope creep,
but don't want to leave iVDGL iGOC subproject hanging either.*

# [Removed Materials Beyond This Point]{.mark}

**[delete or relocate the following sections:]{.underline}**

# [Progress -- June 1 2001 to Dec 31 2001]{.mark}

[This header to be removed, and a separate progress report for this
period to be supplied.]{.mark}

# [Remainder of Year 1 to September 30, 2001]{.mark}

[Items from this section that are still relevant and to be done will be
moved to latter sections.]{.mark}

## Overall Goals

Our primary goals in Year 1 are to lay the groundwork for the project,
by:

-   Completing initial definition of our virtual data grid architecture,
    and prototyping initial virtual data ideas.

-   Establishing the first version of the VDT, "Basic Grid Services,"
    providing basic security, information, metadata, CPU scheduling, and
    data transport services.

-   Creating a "VDT Canonical Application" that captures key elements of
    virtual data concepts.

-   Defining VDT requirements in each application, and conducting
    proof-of-principle computations to explore these requirements.

-   Establishing research projects aimed at furthering the longer-term
    goals of the project.

-   Laying the groundwork for the education and outreach program.

Project Planning:

We defined four challenge problems during this period, one per
experiment.

-   ATLAS: capture in a sentence or two.

-   CMS: capture in a sentence or two.

-   LIGO: capture in a sentence or two

-   SDSS: capture in a sentence or two

## Virtual Data Toolkit Development 

We will complete and release a first version of the virtual data
toolkit, VDT-1, providing basic grid services. This software release
will provide an *initial set of grid enabling services and tools*,
including security, information, metadata, CPU scheduling, and data
transport. VDT-1 will support efficient operation on O(10 TB) datasets,
O(100) CPUs, and O(100 MB/s) wide area networks and will build
extensively on existing technology.

VDT 1.0 will provide three distinct software packages:

-   Server code to be installed on a data grid node: GIB (GSI, MDS,
    GRAM, GridFTP)

-   Client side programs and libraries for use in client scripts and
    applications: DAGMan, Condor-G; client-side MDS, GRAM (?), GridFTP;
    replica catalog, replica management

-   Standalone services: replica catalog

Specific milestones: \[Need to check dates!\]

-   \[??\] (Virtual data) Deploy centralized metadata and replica
    catalog services. Develop tools for managing catalogs.

```{=html}
<!-- -->
```
-   Definition of VDT v1.0 components and negotiation of schedule: July
    20

-   Packaging and documentation of server-side functions (provided by
    GiB + GridFTP): Aug 1

-   Packaging and documentation of replica catalog server installation:
    Sep 1

-   Packaging and documentation of client side: Sep 1

-   Establish VDT support system, with goal of transitioning to GRIDS
    Center: Sep 1

-   Release of VDT 1.0: Sep 1

Dependencies:

-   Replica catalog and replica management tools (ANL, ISI)

## Research Accomplishments

The *VDT Canonical Application* is intended to provide a vehicle for the
... \[to discuss: Miron suggests that we need this to enable CS to work
independently of applications.\]

We will complete definition of virtual data ...

a.  \[UC,ISI\] (Overall) In collaboration with application scientists,
    complete Data Grid Reference Architecture v2 \[Draft by July 15,
    final version following review by September 1\].

b.  \[UC,ISI,UW\] (Virtual data) Complete design of first version of
    virtual data catalog.

c.  \[??\] (Virtual data) Develop basic information model to represent
    data elements, the relationships between different data types and
    the characteristics of data elements. Develop protocols for storing,
    discovering and retrieving these models. Design and develop tools
    for creating, accessing and manipulating these models by interactive
    tools, and planning and scheduling tools.

d.  \[UC\] (Request execution) Complete prototype of data grid
    simulator, with documentation. Initial paper evaluating alternative
    data replication strategies.

e.  \[??\] (Request execution) Develop a set of global and local policy
    scenarios that reflect the requirements of the user communities of
    the four physics experiments.

f.  \[ISI\] (Request execution) Develop uniform policy representation
    for code, data and resource access.

g.  \[UW, UC\] Develop plan for GridFTP/NeST integration, focusing in
    particular on space management.

h.  \[UW\] (Request planning) Complete work enhancing the ClassAd
    language to support events and triggers.

i.  \[UW\] (Request planning) Develop generic models for representing
    execution plans. Define a set of API and tools for constructing,
    traversing, and manipulating plan data structures. Develop protocols
    and formats for storing and exchanging execution plans

j.  \[UW\] (Request execution) Develop simple optimization heuristics.
    Initial thrust will be on data movement only and focus on the use of
    alternative, or branching plans to compensate for both resource
    failure and changes in resource performance. Implement planning
    heuristics in prototype planning module. Evaluate performance of
    alternatives with simulation and model based studies, as well as
    execution on GriPhyn testbed.

k.  \[UW\] Develop and evaluate a task control language capable of
    capturing the requirements, preferences and dependencies of a PVDG
    request. Implement prototype of an interpreter to a basic subset of
    the language.

l.  \[UW\] Develop a protocol for information exchange between the
    execution and planning agents.

m.  \[UW\] (Request planning) Enhance the \"Gang Matching\" capabilities
    of the ClassAd language and add these enhancements to the run-time
    support library.

n.  \[UCSD\] (Fault tolerance) Produce a paper detailing fault-tolerance
    issues in GriPhyN. Jenny Schopf will be involved, also perhaps Miron
    Livny. \[Oct 1\]

o.  \[UCSD\] (Fault tolerance) Define fault tolerance model for replica
    management utilities. (& implement?) \[Oct 1\]

## Education and Outreach

Specific milestones are as follows:

c.  \[UTB\] Install VDT software on UTB cluster (Oct 1).

d.  More ...need to fill in from material from Manuela and Joe.

# Year 2: October 1, 2001 to September 30, 2002

## Overall Goals

Our primary goals in Year 2 are as follows:

-   Develop a solid set of virtual data software, addressing
    materialization.

-   Have at least two experiments do production computing using VDT 1,
    using distributed resources.

-   Achieve solid results from research projects established in the
    first year, with potential paths for transitioning to production
    software identified.

-   Achieve concrete results from the Education and Outreach program.

## Research Accomplishments

[[Following is miscellaneous stuff collected from various
places]{.underline}:]{.mark}

(Virtual data) Develop techniques for representing data transformations,
and integrate these techniques into the information model. Develop
methods and catalogs for categorizing and curating code elements.

(Virtual data) Extend catalog services to support distributed and
replicated catalogs. Develop techniques for failure detection and
fail-over in the situation of catalog failure.

(Fault tolerance) Examine the issues of \"consistency\" in the data
replication services and virtual data. there are three kinds of
consistency that have come up so far: (1) replicated metadata; (2)
replicated data (being a grid file service, there is less trust one can
place in repositories); (3) dependency tracking - being able to trace
the effects of an error introduced by an application or filter.

\[UW,UC, LBNL\] Define NeST/Globus/DRM integration with the goal of
producing a managed storage element architecture.

## Virtual Data Toolkit Development

**VDT-2 (Centralized Virtual Data Services)** provides a *first set of
virtual data services and tools*, including support for a centralized
virtual data catalog, centralized request estimation, centralized
request planning, network caching, and a simple suite of distributed
execution mechanisms. Representation and exchange of local policies will
be supported for network caches.

## ATLAS

[Summarize milestones/goals from Y2 detailed plan.]{.mark}

## CMS

[Summarize milestones/goals from Y2 detailed plan.]{.mark}

## LIGO

[Summarize milestones/goals from Y2 detailed plan.]{.mark}

[Goals]{.underline}:

[Milestones]{.underline}:

Work on LIGO continues with work started in the last period. Specific
milestones are as follows:

a.  \[CIT\] Use LIGO virtual data to drive display. \[April 1, 2002\]

b.  \[CIT\] Complement implementation of checksum/backup with GridFTP
    \[April 1, 2002\]

c.  \[CIT\] Implement replica catalog and conduct full-scale replication
    \[July 1, 2002\].

d.  \[CIT\] Start work on runs and validation of pulsar search code with
    Condor farms.

e.  \[CIT\] Continue runs and code validation Condor farms \[Jan 1,
    2002\]

f.  \[CIT\] Full-scale search with LIGO science data. \[Apr 1, 2002\]

[Dependencies]{.underline}:

## SDSS

[Summarize milestones/goals from Y2 detailed plan.]{.mark}

[Milestones]{.underline}:

Install second generation iVDGL software.  Tests of code migration to
other iVDGL sites.  Grid-enable gravitational lensing application code. 
Integrate first SDSS data release.

## Education and Outreach

## Coordination

We will hold (or have held) the following meetings:

-   All-hands meeting, LA, Oct 15-17, 2001. (took place).

-   CS research meeting(s): informal meetings held at ISI (Nov 01),
    Caltech (Nov 01) Fermilab (Dec 01) (took place).

-   Application/VDT integration meeting: Jan 8, 2002.

-   All-hands meeting, Chicago, April 8-10, 2002.

[^1]: UCB graduate students are only funded for 4 years.

[^2]: UF also has cost sharing for a project coordinator and part of an
    administrative assistant

[^3]: The UT Brownsville LIGO staff person is Manuela Campenella, who is
    in fact focused primarily on Education and Outreach.

[^4]: The UW Milwaukee staff member, Scott Koranda, is funded 1/3 by
    NCSA in support of GriPhyN.