# Presentation: 268044

## ATLAS, U.S. ATLAS, and Databases

**PCAP Review of U.S. ATLAS Computing**
**    **
**Boston, Massachusetts**
**26 October 2000**
**David Malon**
**malon@anl.gov**

## Outline

**Brief history**
**Organization**
**Scope**
**Status**
**Priorities**
**Plans and related milestones**
**Personnel**

## Brief organizational history

**Worldwide, only one person was significantly involved in ATLAS offline database work 18 months ago (RD Schaffer, Orsay)**
**Last summer, U.S. involvement in ATLAS databases began, with a pilot project that delivered the first production use of Objectivity/DB in ATLAS (tile testbeam data)**
- interesting architecturally in several ways; reported on in the January DOE/NSF review
**Concurrently, ATLAS software reorganization led to creation of a database coordinator position, and appointment of database task leaders for each subsystem **
**David Malon (Argonne) was asked to assume joint responsibility with RD Schaffer for database coordination approximately one year ago**

## Database coordination:  first steps

**Period began with database responsibilities not very clearly defined, and little available core development effort**
**Responsibilities of subsystem task leaders articulated **
- probably too conservatively, in retrospect
**Moderately detailed database PBS submitted to the Computing Oversight Board (COB) in March 00:  18 top-level database work areas, 105 second-level entries (database was first domain in ATLAS computing to do this at any significant level of detail).  Planning has evolved further since then.**
**Near-term work plan and milestones submitted to COB in April/May; incorporation into the ATLAS computing plan has been ongoing since March **
**Specific steps taken to shed inherited responsibilities that are not strictly database (ongoing)**

## Database scope

**Scope remains dauntingly broad, encompassing, among other things, **
- event store infrastructure (persistent event logical and physical structure, inter- and intra-event references, event storage and retrieval infrastructure, collections, tags, metadata, query/selection mechanisms, ...)
- common persistency infrastructure for simulation, for reconstruction, for analysis
- database support for testbeams
- calibrations and conditions databases, including alignment, and time-based retrieval infrastructure
- connections to control framework
- general database infrastructure (physical clustering, physical storage management, session control, transaction management, data protection, tertiary storage connections, ...)

## Database scope II

**...****and more:**
- physical and readout geometry databases
- support infrastructure (release support, reference databases, id management, schema management, database product validation/upgrade/migration, support and consulting, production services, ...)
- data replication and distribution, including coherence and consistency management
- related:  connections to data grid infrastructure
- datastore technology evaluation/comparison
- connections to production (fabrication) databases
- connections to online data sources
- ...and still more (see PBS)...
**As daunting as this looks, inherited responsibilities were broader and deeper still**

## Challenge:  Database Scope

**Historically, overly broad**
- Example:  Event model--has deep database ramifications, but database does not need to own it
- Example:  Detector description--like event model, has extensive database implications, but database domain should not need to define, for example, the ATLAS hierarchical component naming scheme
**Historically, overly deep**
- Example:  core database developers should not be the ones decoding TRT digits from Zebra files, or defining calibration objects

## Addressing the Problem of  Scope

**We have successfully convinced the Computing Oversight Board of the need to reduce the scope and/or distribute responsibility**
**Event model:  chief architect is now overseeing this (COB agreement March 00)**
- ...but shedding responsibilities is gradual--current ATLAS TDR event model remains a database coordinator responsibility
**Detector description:  coordinator outside the database domain (Stan Bentvelsen) named in September 00**
- Prior to that point, database coordinators organized detector description sessions at Architecture Workshop, and a special detector description workshop at the August Software Week
- Stan is beginning with input format (XML) for ideal geometry data, and input to simulation
- Responsibility for time-varying conditions handling will likely move only gradually
- Database still has legacy responsibility for logical identifiers and related infrastructure, and more

## Addressing the Problem of  Scope II

**Move responsibilities to subsystem database task leaders **
- transfer responsibility for subsystem-specific hits, digits, geometries, calibrations, testbeam event structure to subsystems
- increase subsystem role in prototyping/developing candidate technologies (but this is hard)
**We have underutilized subsystem task leaders**
- too much waiting for core infrastructure to be delivered before subsystem roles begin, with almost no core development effort available
- remedying this:  Objectivity training for subsystem people 16-18 October, followed by two-day database workshop

## Database activities:  preamble

**Following slides outline database near-term activities, status, and plans**
**Database priorities for ****content support**** are largely determined by the overall schedule for support of reconstruction, simulation, and mock data challenges**
- see David Quarrie’s talk for details
**This talk will try to highlight, therefore, specific near-term priorities, but also near-term database work that may not be immediately obvious from the architecture plan, e.g., **
- large-scale data and storage management
- support for testbeams
- conditions databases
- early grid connections
- technology evaluation and comparisons to support a datastore product decision

## Challenge:  Competing Priorities

**Voice 1:****  highest database priority is testbeam**
**Voice 2:****  provide TDR hits (not just digits) now, in Objectivity by the end of the year**
**Voice 3:****  organize detector description effort now; meet with outside institutes to recruit effort**
**Voice 4:****  database storage and access through the framework now**
**Voice 5:****  tile pilot code into Athena now (rationale:  introduction to event views, way of connecting Objectivity data to the framework, and starting point for detector description architecture definition) **
**Voice 6:****  ROOT versus Objectivity comparisons, HepMC into Objectivity by September, more...**
**Voice 7:**** data management integration into grid work from the outset**
***...******and this is just the stuff due tomorrow!***

## Near-term Priorities

**Access to existing data**
**Infrastructure for database creation, population, distribution, and development**
**Mechanisms to support data access through the prototype control framework and its successors**
**Initial detector description infrastructure, including detector component identification, and input geometry**
**Datastore support for testbeams**
***These are adjudicated priorities, based upon competing pressures.  The database coordination effort (if not the database development effort) needs to keep these and many, many more balls in the air*****.**

## Access to Existing Data

**This refers primarily to data from the physics TDR.**
**Related milestones:**
**April 00:  Geant3 digits available**
**August 00:  Geant3 hits available**
**Update:**
**Digits are available**
**Release 1.1.6 will contain hits for Pixels/SCT/TRT and MDT**
**Subsystems have primary responsibility for the rest (cross your fingers)**
**December 00:  target for TDR digit availability ****from Objectivity/DB**

## Infrastructure

**...****for database creation, population, distribution, and development**
**Milestones:**
**October 00:  SRT-based support for database creation with reference schemata**
**October 00:  Support for database distribution to secondary federations**
**Update:**
**Prototype of first milestone demonstrated at October database workshop**
**The hope was to deliver these earlier, but lack of core personpower and uncertainties about SRT (the ATLAS configuration management tool) have not helped.  **

## Data Access through Control Framework

**Related milestones:**
**September 00:  prototype Objectivity/DB data access through control framework**
**Literal milestone ****met****:  U.S. initiative demonstrated tile testbeam data access through the framework (read only)**
**We wrote last May that *****“Access to TDR data via Objectivity/DB needs prioritization ******(but see Physics Coordinator’s milestone:  end of 00)******,”***** but some of us had hoped to deliver read access to TDR digits from Objectivity in this timeframe**
**Partition of database responsibilities has meant that the U.S. has NOT played a role in the latter, but we may need to change this in the best interests of ATLAS**
**December 00:  Prototype read/write access to Objectivity data through Athena **

## Milestone Update:  Data Access through the Framework

**Access**** to Objectivity data through the Athena framework has been demonstrated with tile testbeam analysis examples**
- This is also the first exercise of Gaudi’s detector data service in ATLAS
- in many ways, more complex architecturally than event data service
- Supports a non-Gaudi style of data access, less dependent upon smart pointers
- Provides foundation for exploring event views in Athena (cf. tile testbeam detector-centric views) that may help inform the StoreGate model
- Instructive in that it implements several approaches to transient/persistent separation that differ from Gaudi’s approach
**October 00:  A rudimentary Objectivity persistency service, generic and NOT based on the tile design, is proposed to be delivered for use by liquid argon **

## Detector Description Infrastructure

**Including detector component identification, and input geometry**
**Related milestones:**
**April 00:  Shared identification conventions and definitions (STATUS:  draft circulated in April; awaiting endorsement by subsystems--report from RD later)**
**July 00:  Revised identifier utility classes and utilities (STATUS:  first version done in 1998; revision in progress)**
**November 99:  XML DTD for geometry (STATUS:  done, with several subsequent revisions)**
**Summer 00:  XML geometry definitions from subsystems (STATUS:  in progress; subsystems are responsible)**
**November 99:  XML DTD for materials, and XML materials definitions (STATUS:  done; evolving to common implementation with LHCb)**
**Organizing the broader detector description effort was the topic of a 28 August 00 database-organized workshop.**

## Milestone Update:  Detector Description

**New draft of identifier proposal was circulated to subsystem software coordinators and database coordinators in late September (this remains, for better or worse, a ****legacy database responsibility****)**
**muon scheme pending October meeting**
**Stan Bentvelsen has been asked to lead detector description effort, particularly as it pertains to geometry**
**Effort is beginning to broaden**
**earlier, focus was primarily on input format for ideal geometry**
**now, more attention to satisfying simulation requirements**
**thinking about detector description ARCHITECTURE is beginning**
**Amsterdam workshop on geometry specification and XML held 28-29 September**

## Datastore Support for Testbeam

**Related milestones:**
**July 99:  Tile calorimeter testbeam pilot project using Objectivity/DB (STATUS:  completed)**
**July 00:  RD45 calibration database infrastructure in place**
**August 00:  RD45 naming; support for user data areas in shared federation**
**August 00:  Testbeam data models (subsystems have primary responsibility)**
**September 00:  Current tile testbeam data model connected to control framework (done)**
**October 00:  Tile and LAr data available through framework**

## Milestone Update:  Testbeam

**If tile electronics had been ready this summer, we might have been in trouble:  core software components for testbeam (database infrastructure, conditions databases, event model) were not sufficiently advanced**
**May 2001 is a serious target:  series production modules in testbeam**
**Subsystem-specific development will need to come from subsystems--insufficient personpower available in core effort**

## Milestone Update:  Conditions Databases

**Very active right now**
**serious requirements assessment underway (LHCb, COMPASS, ATLAS, and now CMS) for an IT-supported product**
**Claire Bourdarios (Orsay) is coordinating the ATLAS requirements effort, and testing a current incarnation of the software in liquid argon testbeam **
**broad involvement of online community (including developers of the DAQ-1 online bookkeeping system), and testbeam; also reconstruction**
**we hope that this becomes software we will not need to write**

## Other Database Activities

**Viability assessment of ATLAS baseline datastore strategy to support technology decision in appropriate timeframe, which is ...**
**2001? (oft-quoted, based on the Computing Technical Proposal) **
**2002? (Computing TDR)**
**Currently a 2001 “floating milestone” in the ATLAS plan**
**does the ATLAS transient/persistent separation reduce the urgency?**
**New hits and digits definitions, to support, for example, Geant4-related milestones:  2001**
**Grid-related database work**

## Viability Assessment of Baseline Database Strategy

**In the current calendar year, the principal components of that effort are proposed to be:**
**Accumulation of a significant body of experience with Objectivity/DB**
**based in part upon testbeam, but primarily on TDR data**
**specific technology use and evaluation**
**Reassessment of ATLAS requirements**
**LHC common effort**
**ATLAS-specific, in conjunction with Architecture Team requirements effort**
**Evaluation of scalability/viability testing done by others**
**RD45, CMS, BaBar**
**also experiments that have chosen not to use Objectivity/DB**
- This effort may require augmentation based upon Hoffmann review outcomes.

## Grid-related Database Activities

**Proposed current-year milestones:**
- Grid-enabled support for database distribution to secondary federations
- Connections to grid-based replica management for data replicated at remote sites
**These milestones are somewhat aggressive, and rely upon grid project funding (e.g., PPDG and EU Datagrid).**
**They are well matched to current (modest) grid software capabilities.**
**We expect grid projects to augment database efforts, not to dilute them.**
**Our call for volunteers at the last ATLAS grid workshop was clear:  ****we expect a collaboration with CMS here.  We propose concretely to use the CMS GDMP product.**

## Large-scale data and storage management

**Kasemann panel of the Hoffmann review of LHC computing has correctly pointed out that experiments have focused much more on object persistency than on data management**
**Imagine 5 petabytes of data distributed over 1,000,000 5-gigabyte files.**
***How much of the scalability challenge will depend upon the format of the data within those 1,000,000 files, whether it be ROOT or Objectivity or XML or something altogether different?***
**Kasemann panel proposes an LHC-wide Technical Assessment Group convened by the computing coordinators to address such issues**
- EXCELLENT candidate for collaborative work
- ATLAS database coordinators and computing management fully endorse this effort
- will be an important component of database effort once review  recommendations are enacte

## Requirements reassessment

**Another outcome of the Kasemann recommendations (and a recommendation of an earlier LCB review of the RD45 project) will be reassessment of experiments’ requirements for a datastore**
- revisitation of requirements posed in computing technical proposals several years ago in the light of new developments and experience gained in the interim
- EXCELLENT candidate for LHC-wide collaboration
- not yet underway, but important to initiate in time to inform ATLAS technology evaluations and decision-making

## Notes on Milestones

**Note that this program, while ambitious, does NOT address all of the immediate and changing priorities being imposed upon the database domain**
**Example:  HepMC**
**proposed by Architecture Review Committee**
**excellent match to US-managed work on generators, and on connecting generators to framework**
**well matched to ATLFAST effort (early framework adopter)**
**proposed, in fact, as part of the US database plan last January to DOE/NSF**
**Example:  ROOT/Objectivity comparisons**
**in the plan as a likely 2001 activity, at least as a demonstration of physics codes’ independence of underlying datastore **
**should be undertaken as one component of a systematic evaluation of ATLAS baseline strategy **

## Milestone Update:  Other Milestones

**There ARE other milestones on the horizon**
**Prominent example:  pileup handling (December 00(!))**
**there are many infrastructure components that must be in place to accomplish this--not just database**
**Most content-related database milestones are corollaries of overall architecture milestones (see David Quarrie’s slides)**

## Overall database technology evaluation strategy

**Provide the foundation for a fair and comprehensive evaluation of ATLAS baseline strategy, based on ATLAS experience**
**First step:  substantial deployment of ATLAS baseline technology**
**Second step:  user testing, experience, and feedback**
**Learn what we can from the experience, testing, and decisions of other experiments**
**Revisit requirements in an LHC-wide initiative**
**Assess baseline against these requirements, and understand alternatives in this context **
**Undertake specific tests and comparisons**

## Which of these are planned for 2000?

**Proposed in April to COB and described in May at Software Week; reiterated in July and in The PLAN:**
**Accumulate a substantial body of experience with baseline technology**
- based on TDR data, testbeam, and (proposed) HepMC and ATLFAST
**includes Objectivity/DB 6.0 evaluation**
**Survey and try to understand the experience of others**
**Revisit requirements (LHC-wide)**

## Technology evaluation plans

**Evaluation MUST be done with respect to REQUIREMENTS**
**Timetable and specific evaluations depend upon the requirements reassessment timetable and conclusions**
**User experience**
**Based upon widely deployed baseline**
**While most users should be insulated from the datastore, it is important that more than a couple of people understand the baseline technology**
**training in October**
**Scalability assessment**
- Plans requested by the ATLAS Architecture Review Committee chairman for December review; preliminary document in progress

## Proposed 2001 tests of database functionality, usability, and scale

**Initial:  many users reading from shared data sources**
**akin to current TDR data access from Athena,  with Objectivity, rather than Zebra files, as the data source**
**Shared access to database at terabyte scales**
**How do we ensure that this is really a terabyte-scale test, I.e., that most of the database is used/usable?**
**Developers tend to read the same few runs over and over again**
**Pileup studies**** (consistent with ATLAS 2001 plans) are attractive in this regard--delivering randomly chosen samples of minimum bias events provides better database coverage ****(can learn from CMS here)**
**Ability to accomplish terabyte-scale testing with meaningful data may depend upon the state of simulation and reconstruction efforts**
**Parallel database population (emulating reconstruction farm)**
**This may test our model, our collection management, and related infrastructure as much as it tests the database**

## Census:  Core Database Personnel

**2+ people total today**
- David Malon (Argonne):  ATLAS database coordinator; also on other related projects (e.g., grids)
- RD Schaffer (Orsay):  ATLAS database coordinator; also on Architecture Team
- (ramping up) Antoine Perus (Orsay):  partially dedicated to core database (Geant3 digits into Objectivity)
- These people are also responsible for components of architecture effort, event model, detector description architecture, geometry, conditions, worldwide computing model development, grid data infrastructure; they need to participate in simulation and reconstruction software working groups, maintain liaisons to online efforts, contribute to online data model, coordinate with production (fabrication) database efforts, participate in RD45, LHC++, COCOTIME, CSG, ...
*Coordination of the many database responsibilities and liaison with the many stakeholders leaves little effort available for core development.*
*...**and don’t forget REVIEWS...*

## Core database personnel:  near-term expectations

**3.0 FTE U.S. core effort (in FY 01 allocation letter)**
**3.0 FTE Orsay database effort (new hire expected by the end of the year)**
**1 FTE requested from computing group at CERN for database administration, infrastructure support and development**
**Involvement by Lisbon group (involved in online bookkeeping database) in conditions databases**
**Prospects of Italian involvement currently being cultivated**
**Leverage of grid enthusiasm expected (in Italy, UK, and US)**

## Census:  Subsystem Database Personnel

**Subsystem database representatives**
- Stan Bentvelsen  (Inner Detector)
- Stefan Simion  (Liquid Argon)
- Steven Goldfarb  (Muons)
- Tom LeCompte  (Tile Calorimeter)
- Hans Peter Beck  (Trigger/DAQ)
**Inner detector**
- Stan’s database-related work supports the XML geometry effort (AGDD and G4Builder)
**Liquid argon**
- some work on AGDD version of LAr geometry
- Claire Bourdarios is now working part-time on conditions databases for testbeam

## Census:  Subsystem Database Personnel

**Muons**
- XML work ongoing, including effort by Michigan to automate import of AMDB data into ATLAS XML format (AGDD)
- access to Geant3 digits from TDR data still ongoing (TGC digits due this summer)
- volunteered to test XML-into-useful-Geant4-geometry this year (thanks!)
**Tile**
- updating last year’s testbeam data model for ‘00
- some XML geometry work ongoing
**Trigger/DAQ**
- liaison to online event model and DAQ-1 format issues

## Subsystems and Databases:  Observations

**Subsystem database coordinators have other duties; many of them spend SIGNIFICANTLY under half their time on database-related work**
- Rough guess:  related effort by subsystem database coordinators SUMS to about 1.1 FTE
- Physics Coordinator wants to require that these be full-time positions
**MOST of the work done by these coordinators is ****Detector Description, not Database**
- This is not intended to disparage:  detector description is an urgent need, too (and remember that the database domain still has responsibility for it)
- the XML effort is widely tauted by ATLAS Computing Management as one of the grassroots successes of ATLAS software
- Steven Goldfarb (Michigan) has provided important leadership here, organizing two XML workshops and trying to encourage common approaches among LHC and other experiments

## Subsystems and Databases:  Observations

**A model in which core infrastructure is developed, and then handed with examples to subsystem people to flesh out the content, has not worked as well as intended **
- insufficient core effort to deliver that infrastructure, for one thing
- have worked to remedy this in part by providing database training for subsystem task leaders so that they can jump in at an earlier stage
- this is not an unmixed blessing--several subsystems will need to identify new coordinators, because their current task leaders have insufficient time for this expanded role

## FY 01 U.S. Proposed Database Funding Allocation

**Provides 3.0 FTEs of effort at Argonne****--minimal critical mass threshhold for database effort (unanimous agreement on this by US ATLAS computing management, and by previous review panels)**
- have identified and interviewed several very strong prospects with relevant experience from other experiments
**This effort supports US contributions to:**
**Database infrastructure and connections to control framework**
**Initial database support for simulation (effort rampup in subsequent years)**
**Collaborative work with other domains in areas with serious     database ramifications, such as event model and detector description**
**Database domain oversight and management**

## Summary

**A formidable amount of work confronts the ATLAS core database effort.**
**Substantial progress has been made in “projectizing” this effort, and in shedding non-database legacy responsibilities.**
**Core database development has until now faced a severe shortfall of available effort.**
**The U.S. has formulated a consistent and credible response to this need, without attempting to provide the ENTIRE solution.**
**ATLAS database coordinators have sought and identified non-U.S. sources of effort to help meet database milestones.**
**The database domain has articulated concrete plans to leverage collaborative efforts with other LHC experiments, in grid work, in storage management, in common requirements reassessment, and in making use of IT-provided technologies (e.g., conditions databases) wherever possible.**