# Presentation: 323582

**0**

**Fermilab SW&C Internal Review**
**Oct 24, 2000**
**David Stickland, Princeton University**

- CMS Software and Computing Status
- The Functional Prototypes

## Milestones

**Functional Prototype Milestones exist for:**
**Simulation**
**OSCAR**
**Reconstruction and Analysis Framework **
**CARF**
**Detector Reconstruction**
**ORCA**
**Physics Object Reconstruction**
**ORCA and PRS Analyses**
**User Analysis**
**IGUANA**
**Event Storage and Reading from an ODBMS**
**GIOD; MONARC; ORCA Production**

- DPS Oct/3/2000

## Deliverables for each of the Software Functional Prototypes

**Documented set of use-cases / scenarios / requirements**
**These are not (yet) very formal**
**Suite of software packages / prototypes **
**Public releases of associated software**
**Documentation of components (user-level and reference)**
**Software infrastructure**
**Public software repository**
**Build / release / distribution / documentation systems**
**Multi-platform support both centrally and in remote institutes, ...etc...**
**Proposal for a baseline**
**recommendations on main design and technology choices**
**Proposed project plan for next phase**

- DPS Oct/3/2000

## Simulation

**Current simulation by our GEANT3 product: CMSIM**
**Migration underway to GEANT4**
**We require GEANT4 for its Physics processes and OO implementation**
**FAMOS project underway for Fast Simulation**
**Will be vital to complete many topics in the Physics TDR**
**The FAMOS project is preparing for its first release this autumn **

- DPS Oct/3/2000

## OSCAR (CMS G4 Simulation)

**OSCAR project for CMS implementation of GEANT4**
**Proof of concept reached in July 1998**
**Built barrel geometry**
**Functional Prototype: originally due Dec 1999, slipped by 6 months**
**Delayed due to manpower problems**
**Persistent hits not yet implemented**
**Geometries for most sub-detectors ready**
**Many performance tune-ups completed**
**June 2000, milestone passed but with severely limited functionality **
**CMS recognizes that this project is slipping such that it would become  a critical path item and is addressing these issues now**

- DPS Oct/3/2000

## ORCA

_**O**_**bject **_**R**_**econstruction for **_**C**_**MS **_**A**_**nalysis**
**Project started in Sept. ‘98**
**Currently in fourth major release  (4_3_0)**
**Based on CARF framework**
**Large base of detector code**
**Detailed digitization with Pileup. Persistent storage**
**L1 trigger simulation**
**Clusters, Tracks, Muons, Jets, Vertices**
**Being used by physicists in their studies**
**Not yet persistent**
**Much tuning remains to be done, but the groundwork is in place**
**Very little Fortran code remaining (mostly associated with the GEANT3/CMSIM interface)**

**Has been major focus of SW activity for last two years**

- DPS Oct/3/2000

## Use of ORCA

**Physics/Trigger results related to HLT. See TRIDAS session.**
**Digitization is resource intensive stage**
**200 events pileup for each signal event**
**Trial production in Oct 99**
**Major Production in Spring 2000**
**Simulation Worldwide **
**Digitization and reconstruction at CERN**
**200 CPUs, 2 weeks production, 70TB data transferred**
_**2 million events **_**with full  pileup at 10****34**** luminosity**
**~4TB of data stored and analyzed**
**Third production now underway**
_**5 million events**_**   (ie. Pileup: 1 Billion events!)**
**Simulation **_**and**_** Reconstruction Worldwide**
**GLOBUS/GRID based tools for Database import/export **

**Digitization of one CMS event at full luminosity requires (from first principles) about 400 times more computing than one Run II event**

- DPS Oct/3/2000

## ORCA Production 2000

**ORCA Production 2000**

**Signal**

**Zebra files**
**with HITS**

**ORCA**
**Digitization**
**(merge signal **
**and MB)**

**Objectivity**
**Database**

**HEPEVT**
**ntuples**

**CMSIM**

**HLT Algorithms**
**New **
**Reconstructed**
**Objects**

**MC Prod.**

**ORCA Prod.**

**HLT Grp          Databases**

**ORCA**
**ooHit**
**Formatter**

**Objectivity**
**Database**

**MB**

**Objectivity**
**Database**

**Catalog import**

**Catalog import**

**Mirrored Db’s**
**(US, Russia, Italy..)**

- DPS Oct/3/2000

## Production Farm (Spring 2000)

_**Shift 20**_
**Digit DB’s**
**Pileup “Events”**
**Lockserver**

_**eff031**_
**jetmet FDDB**

_**eff032**_
**jetmet journal**

_**eff103**_
**muon FDDB**

_**eff104**_
**muon journal**

**70 CPUS used for jetmet production**

**70 CPUS used for muon production**

**24 nodes serving Pileup “Hits”**
**eff001-10,33-39,76-78,105-108**

**6 nodes serving all other DB Files from HPSS**
**eff073-75,79-81**

**HPSS**

**HPSS**

**Objectivity **
**communication**

**Data Flow**

**On loan from EFF**

- DPS Oct/3/2000

## Performance

**More like an Analysis facility than a DAQ facility**
**140 jobs reading asynchronously and chaotically from 30 AMS server’s, writing to a high speed SUN server**
**Non disk-resident data being staged from tape**
**70 jetmet jobs at ~60 seconds/event and 35MB IO/event**
**70 muon jobs at ~90 seconds/event and 20MB IO/event**
**Best Reading rate out of Objectivity ~ 70MB/sec**
_**Continuous 50MB/sec reading rate**_
**1million jetmet events, ~ 10 days**
**1million muon events, ~15 days**
**Extensive monitoring was deployed, significant statistics were accumulated and analyzed**

**}**** ****in parallel**

- DPS Oct/3/2000

## Feedback to MONARC Simulations

**Feedback to MONARC Simulations**

**Mean measured Value ~48MB/s**

**Measurement**

**Simulation**

**These productions are a source of high statistics information to calibrate the simulation tools (MONARC)**

- DPS Oct/3/2000

## User Analysis Software Strategy 

**Core software “User Analysis Environment” should: **
**Ensure coherence with framework and data handling**
**Coherent across all CMS software as much as possible**
**Filtering of data sets, user collections, user tags, etc.**
**Emphasize generic toolkits (not monolithic applications)**
**Histogramming, fitting, tag analysis,....**
**Graphical user interfaces, plotting, etc.**
**Interactive detector and event visualization**
**Include supporting infrastructure**
**Support for remote deployment and installation**
**Building against CMS, HEP, and non-HEP software**
**Documentation,...**

- DPS Oct/3/2000

## IGUANA Software Strategy 

**IGUANA Software Strategy **

**Strongly emphasize generic toolkits (not monolithic applications)**
**Core philosophy: *****“Beg, borrow, and exploit”***** software from many sources**

***Event Display***

***Graphical User ***
***Interfaces***

***Histograms,***
***persistent tags***

***Interactive  plotting***

***Fitting and***
***Statistical***
***analysis***

- DPS Oct/3/2000

## IGUANA: GUI / Analysis Components

**IGUANA: GUI / Analysis Components**

- DPS Oct/3/2000

**Notes:**
This shows a simple prototype of a more complete analysis application which uses real data obtained in the CMS Avalanche Photodiode quality assurance laboratory.

## IGUANA Event Display with ORCA

**IGUANA Event Display with ORCA**

- DPS Oct/3/2000

**Notes:**
This shows the interactive detector and event visualisation system of the CMS ORCA reconstruction software. This system is based on the IGUANA 3D interactive visualisation components which in turn use Qt, OpenGL and OpenInventor.

## IGUANA “Functional Prototype”CMS / LHCC Milestone of June 2000

**This milestone was **_**delayed by 4 months**_** for two reasons:**
**1) Two software engineers were required in 1999 and only one was hired. The second engineer joined the project in May 2000. **
**2) The functional prototype should include the Lizard interactive analysis software of the CERN/IT/API group, the first major release of which is scheduled for 15 October 2000. **
**Rescheduled milestone in October 2000 will be satisfied**

- DPS Oct/3/2000

##  Current Analysis Chain

** ****Current Analysis Chain**

**CMSIM (Geant3) Simulation**
**ORCA Hit formatting into ODBMS**
**ORCA Pileup and Digitization of some subset of detectors**
**Selection of events for further processing**
**Create new collection**
**shallow (links), or deep (data) to existing objects**
**add new objects (ie. Tk Digits)**
**replace existing objects if required **
**After ooHit stage, all combinations of**
**Transient  - (Persistent)**
**Persistent - Transient**
**Persistent - Transient - Persistent**
**	****are possible**
**User collections of events of interest**
**Collections can span datasets, navigation back from event data to run data can be used to get correct setups**
**Full ODBMS functionality being used**

**Organization of the Meta-data and production issues, are typically much more technically complex than the *****simple***** issues of persistent objects!**

**Prod.**

**Users**

- DPS Oct/3/2000

## Data Handling 

**We already have more data (********10TB) than disk space **
**use MSS systems (HPSS at CERN, ENSTORE at FNAL)**
**automatic staging by hooks in Objectivity code**
**Tools are in place to replicate federations**
**Shallow (catalog and schema files only)**
**Meta-deep (plus meta-data)**
**Deep (plus Database files)**
**LAN and WAN**
**“****Request Redirection Protocols” being prototyped and field tested**
**allows to “hide” actual data location from users**
**disk goes down, single change on a central server redirects user requests to a new server**
**A powerful place to hook into Objectivity to  give us the required control**

**Leverage products like Objectivity to reduce the amount of SW we have to write**

- DPS Oct/3/2000

## Product- and Project- ize

**Moving from system-scale to enterprise-scale.**
**Productize**
**Make Software products that: **
**are capable of running at all regional centers, **
**give consistent, repeatable and verifiable results**
**have well understood quality**
**have been tested rigorously**
**have controlled change...**
**Rate of increase of new features will reduce as more work goes onto quality**
**Projectize**
**General milestones were satisfactory for the prototype stage**
**Now require a more detailed planning, **
**Attachment of milestones to critical (in-project and off-project) items**
**Filling in of short-term milestones**
**More detailed manpower planning**

- DPS Oct/3/2000

## 5% and 20% Data Challenges

**In 2002/2003 we have 5% and 20% data challenges specified**
**In fact these are just part of a steady process **
**The % we refer to is the % of complexity, rather than the genuine 5% of the data, or 5% of the CPU...**
**Farm sized (in boxes) at 5/20%**
** ****processing speed whatever it is**
** ****run for a period of a  month or so to see the whole system in operation:**
**first pass reconstruction**
**roll data out to users continuously (no scheduled downtimes)**
**selected “streams” (collections) in operation**
**user offline selection -> user collections**
**replication between sites**
**timely “results”**

- DPS Oct/3/2000

## Conclusions

**Technically we are on course**
**Most aspects of the computing model are already being tested in detail**
**User acceptance is big and growing**
**The collaboration is fully engaged in this process**
**Schedules are just being met**
**But detailed planning for the next phase may uncover new critical items**
**Slippage will happen in the absence of more skilled-manpower**
**Both in Core Application Software and in the development of the User Facilities there are vital roles for qualified engineers.**

- DPS Oct/3/2000