# Presentation: 250287

## STAR Overview and OO Experience

- Torre Wenaus
- STAR Computing and Software Leader
- Brookhaven National Laboratory, USA
- CHEP 2000, Padova
- February 7, 2000

## Outline

- STAR and STAR Computing
- Framework and analysis environment
- Data storage and management
- Technology choices
- OO event model
- Database
- Current status
- OO Experience
-                    Emphasis on offline... c.f. Claude Pruneau’s STAR Online talk
- http://www.star.bnl.gov/computing

- CHEP 2000

- Torre Wenaus, BNL

## STAR at RHIC

- RHIC: Relativistic Heavy Ion Collider at Brookhaven National Laboratory
- Colliding Au - Au nuclei at 100GeV/nucleon
- Principal objective: Discovery and characterization of the Quark Gluon Plasma (QGP)
- First year physics run April-August 2000
- STAR experiment
- One of two large experiments at RHIC, >400 collaborators each
- PHENIX is the other
- Hadrons, jets, electrons and photons over large solid angle
- Principal detector: 4m TPC drift chamber
- ~4000+ tracks/event recorded in tracking detectors
- High statistics *per event* permit event by event measurement and correlation of QGP signals

- CHEP 2000

- Torre Wenaus, BNL

## Slide 4

- CHEP 2000

- Torre Wenaus, BNL

## Summer ’99

- Engineering run
- Beam gas event

- CHEP 2000

- Torre Wenaus, BNL

## Computing at STAR

- Data recording rate of 20MB/sec; 15-20MB raw data per event (~1Hz)
- 17M Au-Au events (equivalent) recorded in nominal year
- Relatively few but highly complex events
- Requirements:
- 200TB raw data/year; 270TB total for all processing stages
- 10,000 Si95 CPU/year
- Wide range of physics studies: ~100 concurrent analyses in ~7 physics working groups
- Principal facility: RHIC Computing Facility (RCF) at Brookhaven
- 20,000 Si95 CPU, 50TB disk, 270TB robotic (HPSS) in ’01
- Secondary STAR facility: NERSC (LBNL)
- Scale similar to STAR component of RCF
- Platforms: Red Hat Linux/Intel and Sun Solaris

- CHEP 2000

- Torre Wenaus, BNL

## STAR Software Environment

- In Fortran:
- Simulation, reconstruction
- In C++:
- All post-reconstruction physics analysis
- Recent simu, reco codes
- Infrastructure
- Online system (+ Java GUIs)
- ~75 packages
- ~7 FTEs over 2 years in core offline
- ~50 regular developers
- ~70 regular users (140 total)

- Migratory Fortran => C++ software environment central to STAR offline design

- C++:Fortran ~ 65%:35% in Offline
- from ~20%/80% in 9/98

- CHEP 2000

- Torre Wenaus, BNL

## STAR Offline Framework

- STAR Offline Framework must support
- 7+ year investment and experience base in legacy Fortran
- OO/C++ offline software environment for new code
- Migration of legacy code: concurrent interoperability of old and new
- Fortran developed in a migration-friendly Framework – StAF – enforcing IDL-based data structures and component interfaces
- Evolving StAF to a fully OO Framework / analysis environment judged too expensive in development and support
- Instead, leverage a very capable tool from the community...
- 11/98 adopted new Framework built over ROOT
- Modular components ‘Makers’ instantiated in a processing chain progressively build (and ‘own’) event components
- Automated wrapping supports Fortran and IDL based data structures without change
- Same environment supports reconstruction and physics analysis
- In production since RHIC’s second ‘Mock Data Challenge’, Feb-Mar ‘99 and used for all STAR offline software and physics analysis
- 				cf. Valery Fine’s “STAR Framework” talk for details

- CHEP 2000

- Torre Wenaus, BNL

## STAR Event Store Technology Choices

- Original (1997 RHIC event store task force) STAR choice: Objectivity
- Prototype Objectivity event store and conditions DB deployed Fall ’98
- Worked well, BUT growing concerns over Objectivity
- Decided to develop and deploy ROOT as DST event store in Mock Data Challenge 2 (Feb-Mar ‘99) and make a choice
- ROOT I/O worked well and selection of ROOT over Objectivity was easy
- Other factors: good ROOT team support; CDF decision to use ROOT I/O
- Adoption of ROOT I/O left Objectivity with one event store role remaining to cover: the true ‘database’ functions
- Navigation to run/collection, event, component, data locality
- Management of dynamic, asynchronous updating of the event store
- But Objectivity is overkill for this, so we went shopping...
- with particular attention to Internet-driven tools and open software
-  and came up with MySQL

- CHEP 2000

- Torre Wenaus, BNL

## Technology Requirements: My version of 1/00 View

- CHEP 2000

- Torre Wenaus, BNL

## Event Store Characteristics

- Flexible partitioning of event components to different streams based on access characteristics
- Data organized as named components resident in different files constituting a ‘file family’
- Successive processing stages add new components
- Automatic schema evolution
- New codes reading old data and vice versa
- No requirement for on-demand access
- Desired components are specified at start of job
- permitting optimized retrieval for the whole job
- using Grand Challenge Architecture; cf. David Malon’s talk
- If additional components found to be needed, event list is output and used as input to new job
- Makes I/O management simpler, fully transparent to user
-      c.f. Victor Perevoztchikov’s “STAR Event Data Storage” talk for details

- CHEP 2000

- Torre Wenaus, BNL

## Slide 12

- CHEP 2000

- Torre Wenaus, BNL

## Slide 13

- CHEP 2000

- Torre Wenaus, BNL

## STAR Event Model StEvent

- C++/OO first introduced into STAR in physics analysis
- Essentially no legacy post-reconstruction analysis code
- Permitted complete break away from Fortran at the DST
- StEvent C++/OO event model developed
- Targeted initially at DST; now being extended upstream to reconstruction and downstream to micro DSTs
- Event model seen by application codes is “generic C++” by design – does not express implementation and persistency choices
- Developed initially (deliberately) as a purely transient model – no dependencies on ROOT or persistency mechanisms
- Implementation later rewritten using ROOT to provide persistency
- Gives us a *direct* object store – no separation of transient and persistent data structures – *without *ROOT appearing in the interface

- CHEP 2000

- Torre Wenaus, BNL

## Slide 15

- CHEP 2000

- Torre Wenaus, BNL

## MySQL as the STAR Database

- Relational DB, open software, very fast, widely used on the web
- Not a full featured heavyweight like Oracle
- No transactions, no unwinding based on journalling
- Good balance between feature set and performance for STAR
- Development pace is *very* fast with a wide range of tools to use
- Good interfaces to Perl, C/C++, Java
- Easy and powerful web interfacing
- Like a quick protyping tool that is also production capable – for appropriate applications
- Metadata and compact data
- Multiple hosts, servers, databases can be used (concurrently) as needed to address scalability, access and locking characteristics

- CHEP 2000

- Torre Wenaus, BNL

## Slide 17

- CHEP 2000

- Torre Wenaus, BNL

## Slide 18

- CHEP 2000

- Torre Wenaus, BNL

## MySQL based DB applications in STAR

- File catalogs for simulated and real data
- Catalogues ~22k files, ~10TB of data
- Being integrated with Grand Challenge Architecture (GCA)
- Production run log used in datataking
- Event tag database
- Good results with preliminary tests of 10M row table, 100bytes/row
- 140sec for full SQL query, no indexing (70 kHz)
- Conditions (constants, geometry, calibrations, configurations) database
- Production database
- Job configuration catalog, job logging,  QA, I/O file management
- Distributed (LAN or WAN) processing monitoring system
- Monitors STAR analysis facilities at BNL; planned extension to NERSC
- Distributed analysis job editing/management system
- Web-based browsers for all of the above
-                                                                  cf. Sasha Vanyashin’s NOVA talk

- CHEP 2000

- Torre Wenaus, BNL

## STAR Databases and Navigation Between Them

- CHEP 2000

- Torre Wenaus, BNL

## Current Status

- Offline software infrastructure and applications are operational in production and ‘ready’ to receive year 1 physics data
- ‘Ready’ in quotes: there is much essential work still under way
- Tuning and ongoing development in reconstruction, physics analysis software, database integration
- Data mining and analysis operations infrastructure including Grand Challenge deployment
- Successful production at year 1 throughput levels last week, in a ‘mini Mock Data Challenge’ exercise
- Final Mock Data Challenge prior to physics data is in March
- Stress testing analysis software and infrastructure, uDSTs
- Target for an operational Grand Challenge

- CHEP 2000

- Torre Wenaus, BNL

## OO ‘and related’ Experience and Lessons

- C++ very well suited to modular component architecture and ‘natural’ data models mapping well onto a physicist’s view of physics analysis
- If the latter is true it should ‘sell itself’ once people have such an analysis environment in their hands, and this we do find
- Good response to an OO/C++ analysis environment in a heavily Fortran community
*Evolution* – vital for **continuity** and preserving **experience** base and **productivity** – is practical and effective
- C++ the right choice ... despite the still dismal compiler situation
- Mainstream, designed for performance, close to maturity (we hope)
- Training by practical example and hands-on mentoring required first; formal training found useful later (success with Object Mentor’s advanced OOAD course)
- STAR’s initial pursuit of Objectivity was a mistake
- A monolithic solution, abandoned in favor of a more secure hybrid
- Success in factorizing data management into distinct *object store* and *database* components
- Without compromising OO environment seen by users, or maintainability

- CHEP 2000

- Torre Wenaus, BNL

## OO ‘and related’ Experience and Lessons (2)

- Great success with ROOT as C++/OO tool set and analysis environment available today
- Seen as long term solution for STAR
- But data model and user code can be shielded from specifics, preserving flexibility
- Open software tools and technologies of vital and growing importance
- STAR’s two major commercial software components (Objectivity and Orbix) both replaced with open software/community tools (ROOT/MySQL and Orbacus)
- Commercial product dependencies are a painful burden
- A long list of other open software tools employed by STAR
- Apache and add-ons, perl, php, XML, LXR code documentation, cvsweb, HyperNews, Debian bug tracking, Samba, cons build management, gcc, Linux,... and others.

- CHEP 2000

- Torre Wenaus, BNL

## We Want You!

- Taking blatant advantage of this opportunity...
- I am being replaced! (Moving to ATLAS.)
- The Computing and Software Leader job is coming open
- BNL job posted; hire ASAP
- Talk to me for more info!

- CHEP 2000

- Torre Wenaus, BNL