# Presentation: 345079

## Architecture & Framework

**David R. Quarrie**
**Lawrence Berkeley National Lab**
***DRQuarrie@LBL.Gov***

## Overview

**Architectural Task Force**
**Architectural Vision**
**Architecture Team**
**Framework Design & Implementation**
**Milestones**
**Closing Remarks**

## Architecture Task Force

**Established June 1999**
**Katsuya Amako (KEK)**
**Laurent Chevalier (Saclay)**
**Andrea Dell’Acqua (CERN)**
**Fabiola Gianotti (CERN)**
**Stephen Haywood (RAL) - Chair**
**Norman McCubbin (RAL)**
**Helge Meinhard (CERN)**
**David Quarrie (LBNL)**
**RD Schaffer (CERN+LAL)**
**Marjorie Shapiro (LBNL)**
**Valerio Vercesi (INFN)**
**Torsten Akesson (ATLAS management)**

## ATF - Mandate

**“... ****specify the global architecture of ATLAS computing in a way that provides a unified execution framework for data access, reconstruction, simulation, analysis and event display.”**
**“... ****a database interface making ATLAS independent of database supplier.”**
**“****Full attention should be given to implementations already carried out in previous and upcoming experiments...”**
**“****A first version of the architecture document should be made available to the collaboration at the latest three months after the launch of the taskforce.”**
**“****The taskforce will have a composition taken from a large base in the collaboration so as to ensure that the architecture will be one with a broad support.”**

## Glossary

**Architecture**
**The structure of the system, comprising the components, the externally visible properties, and the relationships among them**
**Framework**
**Represents a collection of classes that provide a set of services for a particular domain**
**A concrete realization of an architecture**
**Component**
**A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces**

## ATF - Work

**Presentations (LHCb, *****B******A******B******AR*****, CDF, D0,...)**
**Architectural Design**
**Two approaches to identify components, responsibilities and relationships**
**Prior experience**
**Unified Software Development Process (USDP) based approach**
**Approaches complementary**
**New insight**
**Validation of experience-based conclusions**
**Merging incomplete at termination of ATF**

## USDP

**Unified Software Development Process**
**Booch, Jacobson, Rumbaugh**
**Unified Modelling Language (UML) as notation**
**Development is use-case driven**
**Multiple phases **
**Requirements, Analysis, Design, Implementation, Testing, *****etc*****.**
**Incremental**
**Iterative**

## USDP Phases

## Core Abstractions

**Modules/Algorithms**
**Computational code**
**Data Objects**
**Module Inputs and outputs**
**Transient objects capable of being converted**
**Converters**
**Convert data from one representation to another**
**Transient/Persistent**
**Transient/Graphical**
**Services**
**Components that provide a support service**
**Stores**
**Several, both transient & persistent**

## ATF - Components

## ATF - Major Decisions 

**Object oriented paradigm**
**C++ implementation language**
**Java forseen**
**Separation of Data and Algorithms**
**See later slide**
**Separation of Transient and Persistent Data**
**Independence from persistent implementation**
**Transient Event Store as scratchpad**
**Owner of intermediate results**
**Communication between Modules/Algorithms**
**Source of data that can be made persistent at end of processing**

## Transient/Persistent Separation

- Data Service

- ODBMS

- Persistency
-  Service

- P

- P

- ODBMS Cache

- Transient Store

- P

- P

- P

- P

- P

- P

- P

- P

- P

- P

- P

- Persistency Manager

- ODBMS Knowledge

## Data/Algorithm Separation

***Not***** functional decomposition**
**Framework schedules computational tasks for objects exhibiting the algorithm interface (modules)**
**Raises issue of granularity**
**Provide guidance for algorithm developers**
**Data objects can be complex and have a significant computational behavior**
**Modules can delegate some processing to data objects**
**Capable of being converted to a persistent representation**
**Data/Algorithm lifetimes are different**
**Data lifetime is the event**
**Module lifetime is the job**

## Architecture Team

**Detailed Design and Implementation**
**Led by Chief Architect**
**Three USA Members**
**David Quarrie (LBNL)**
**Acting as interim team leader**
**Craig Tull (LBNL)**
**Paulo Calafiura (LBNL)**
**One other known Member**
**Katsuya Amako (KEK)**
**Others still being sought by Computing Coordinator**
**Goal is ~6 people**

## A-Team - Work

**Core team augmented**
**Database**
**Graphics**
**Reconstruction**
**Simulation**
**Physics Analysis**
**...**
**Crucial to develop good working relationships outside the team**
**Formal relationship to other computing groups still being understood**
**Very useful feedback from John Harvey **

## A-Team - Approach 

**Not waiting for rest of team to be announced**
**Multi-pronged approach**
**Understand present Computing Infrastructure**
**Preliminary task list & milestones**
**Establish contact with software groups (reconstruction, *****etc*****.)**
**Establish short term working meetings *****etc*****.**
**May prototype based on GAUDI**
**See next slide**
**USDP work**
**Katsuya augmented by Chris Day (LBNL)**
**Chris as software process librarian**
**Experienced in USDP and Rational Rose**

## GAUDI

**LHCb Architecture**
**John Harvey, Pere Mato et al.**
**Embodies a coherent vision**
**Clear distinction between abstractions and implementations**
**Identifies many of the same components as the ATF**
**Not really surprising**
**Mutual incorporation of ideas and experience**
**In third release iteration**

## GAUDI vs BABAR/CDF Framework

**Embodies a more coherent vision**
**Better use of abstractions**
**Capable of using *****B******A******B******AR*****/CDF components**
***E.g.***** *****B******A******B******AR***** ProxyDict as transient event store**
**Better capable of being used in distributed environment**
**Support for multiple scripting languages**
**Suitable for Java**
**Maturity vs. potential**
**Believe GAUDI has more potential**

## Control Framework Major Milestones

**May 2000 Prototype**
**Based on GAUDI**
**Jun 2000 Alpha Release Design Review**
**Sep 2000 Alpha Release**
**Incorporate USDP feedback**
**Mar 2001 Freeze Full Function Release functionality**
**Jul 2001 Full Function Release Design Review**
**Oct 2001 Full Function Release**
**Apr 2002 Freeze Production V1 functionality**
**Distributed (support computational grid)**
***etc.***
**Expect minor releases at ~3-4 month intervals**

## May 2000 Prototype

**Major concern is credibility**
**We can’t afford not to deliver something**
**Crucial to gain acceptance from users**
**Propose to provide something close to PASO shell but with much better functionality and potential for extensibility**
**Easy to incorporate existing development**
**Existing user community**
**Defuse further development on PASO**
**Involve PASO developers with future development in the context of the framework *****etc*****.**

## May 2000 Prototype

**Proposal is to base on GAUDI **
**Basic transient event store**
**Evaluating *****B******A******B******AR*****/GAUDI/CDF versions now**
**Incorporate existing transient event model (Schaffer et al.)**
**Recognize that this needs to be replaced – not scalable**
**Read TDR simulation data**
**Allows existing ATLAS reconstruction modules to be incorporated with only minor changes**
**Extend GAUDI**
**Sequencing Service**
**Commands**
**Command Interpreter instead of job options**

## May 2000 Functionality

**Support for TDR simulation data**
**Existing XML Detector Description Model**
**Existing ATLAS visualization**
**Limited ability for persistent output**
**Sequencing of multiple algorithms/modules**
**Follow *****B******A******B******AR*****/CDF model of multiple paths comprising multiple modules capable of filtering**
**Hypothesis-based processing**
**Each path corresponds to a physics signal**
**Succeeds if event meets filter criteria**
**Dynamic loading of user modules**

## Parallel Development

**Going for a GAUDI-based May 2000 prototype doesn’t mean simple adoption**
**ATLAS-specific implementations feasible and expected**
**Parallel USDP based development**
**Provide new insights**
**Validate & catalog experience-based conclusions**
**Merge in Sep 2000 release**
**Feedback to GAUDI team**
**ATLAS “personality” to GAUDI developed**

## Future Releases

**September 2000**
**Merged USDP/GAUDI**
**Geant3 Simulation integration**
**Wrapped FORTRAN**
**Event Model**
**Run-time configuration**
**Limited Physics Analysis output – Histograms/NTuples**
**October 2001**
**Full Database integration **
**Geant4 Simulation integration**
**Physics Analysis Tool integration**
**Visualization**
**Statistics & Monitoring tools**
**Bookkeeping**

## GAUDI Collaboration

**Development acceleration**
**Reuse of ideas, designs, code, *****etc*****.**
**CERN leverage**
**GEANT4 integration?**
** ****Not all collaborations have been successful**
**I don’t think this will be a problem**
**Common abstractions, different implementations feasible**
**People involved have known each other for many years**
**We have necessary experience if need be**
**Stress need for a rapid prototype that minimizes future upheaval for developers**
**Try to get interfaces stable as quickly as possible**

## Architecture/Framework Personnel

**Architecture & USDP Support**
**David Quarrie (LBNL – 50%) [Architecture team]**
**Chris Day (LBNL – 66%)**
**Framework & Support**
**Paulo Calafiura (LBNL - 50%) [Architecture team]**
**Craig Tull (LBNL - 100%) [Architecture team]**
**Charles Leggett (LBNL – 50%)**
**John Milford (LBNL – 50%) **
**A.N. Other (LBNL – 66%) **
**FTE numbers above are for FY00**
**Good ties to other US-ATLAS personnel**
**David Malon**
**Torre Wenaus, Srini Rajagopalan**
***etc*****.**

## Closing Remarks

**Many changes in last 9 months**
**ATLAS Computing reorganization**
**Architectural vision being established**
**Architecture Task Force**
**Design/Implementation teams being put in place**
**Architecture Team**
**US-ATLAS playing leading role**
**Architecture**
**Framework**
**Database**
**May 2000 prototype is both crucial and feasible**
**Collaboration with GAUDI team**
**Basis of ATLAS-specific control framework**