# Presentation: 285886

## PHOBOS Computing in the pre-Grid era

- PHOBOS Computing in the pre-Grid era

- Burt Holzman
- Head of Computing
- PHOBOS Experiment

## Outline

- “Collision Physics”
- Computing with PHOBOS: now
- Computing with PHOBOS: soon

## Acknowledgments

-    PHOBOS Computing represents years of hard work by many peopleincluding but not limited to
-    Marten Ballintijn, Mark Baker, Patrick Decowski, Nigel George, George Heintzelman, Judith Katzy, Andrzej Olszewski, Gunther Roland, Peter Steinberg, Krzysztof Wozniak, Jinlong Zhang and the gang at the RCF

## Collision Physics

- We (HEP/Nuclear/RHIC) collidebillions (and billions...) of
- electrons vs. positrons
- antiprotons vs. protons
- nuclei vs. nuclei
- ... and a whole lot more

## Collision Physics

- Collision physics is ideal for parallel computing: each collision (“event”) is independent!

- Animation courtesy of UrQMD group

## Collision Physics

- ... and we collect millions of events per day

## RHIC Needs Power

- Event from Delphi (e+ e-)

## PHOBOS Detector

- Ring Multiplicity Detectors
- (Silicon)

## PHOBOS Computing Needs

- Operations (Counting House)
- Simulations (“Monte Carlo”)
-  Must understand detector response and backgrounds
- Production
-  Reconstruct event vertex
-  Reconstruct tracks
- Analysis

## Operations/Counting House

- Data Acquisition
-  PR01-PR04: quad Sparc + SCSI Raid
-  PR05: Big River TK200 data recorder
-  Slow Controls
-  Windows NT running Labview
-  Online Monitoring
-  Datamover

## Online Monitoring

- TPhOnDistributor

- TPhOnDistClient

- TPhOnDistClient

**DAQ**

- Raw Event

- Event

- Event

- Event

- TPhSocketDataFile01

- TPhOnDistClient

- Event

- TPhSocketDataFile01

- Event

- DistClients do
- distributed processing
- of events (HitProcessing, ...)

## “Datamover” design

- Run reconstruction ASAP on data
- This implies:
-  Run calibrations (“pedestals”) in   Counting House
-  Run reconstruction from HPSS disk cache, not HPSS tape

## PR00 datamover

- Users ran calibrations by hand
- Users sunk data by hand
- OK for a really slow DAQ

## PR01-PR04 datamover

- DAQ

- DAQ DISK

- SCSI

- vmesparc

- SCSI

- pedestals

- NFS

- FTP

- ped_daemon

- daq_daemon

- deletor_daemon

- online

- online tells pedestals when to run
- pedestals tells vmesparc when to sink

- HPSS

## PR05 datamover

- DAQ

- DAQ DISK

- pedestals

- NFS

- FTP

- ped_daemon

- daq_daemon

- online

- online tells pedestals when to run
- pedestals tells vmesparc when to sink

- HPSS

- Ramdisk

## Vertex Reconstruction

- _Vertex Resolution:_
- x ~ 450 m
- y ~ z ~ 200 m**    **

- For this event:
- vertex @
- Z = -0.054 cm

- cm

- counts

- Combinatorics can be very expensive

## Particle Tracking

**Road-following algorithm finds straight tracks in field-free region**
**Curved tracks in B-field found by clusters in (1/p, ********) space**
**Match pieces by ********, consistency in dE/dx and fit in yz-plane**
**Covariance Matrix Track Fit for momentum reconstruction and ghost rejection**

- x

**10 cm**

- 1

- 2

**B****y**

- z

- Beam

## Size of the PHOBOS Farm

- 6 dual 733 MHz
- 6 dual 933 MHz
- 11 dual 1733 MHz

- _pharm_

- _All nodes have 2-4 big disks attached_

## LSF Batch

- (for analysis & **simulations**)

## CRS Batch

- (for Production)

## Monitoring: Ganglia

- http://ganglia.sourceforge.net

## ROOT

- PHOBOS Software (“PhAT”) built on ROOT (http://root.cern.ch) framework
-  Automated I/O of objects
-  Very efficient data formats (trees)
-  C++ interpreter (!)

## rootd

- ROOT files accessible via rootd server-side daemon over 100 Mb/s network
- Can be inefficient: data is remote to analysis job (but OK if CPU is bottleneck)

## Distributed Disk

- rcrs4001

- rcrs4002

- rcrs4003

- rcrs4004

- ORACLE DB

- rootd

## Distributed Disk: CatWeb

- Web-based front-end
- Oracle database back-end
- Allows users to stage files to distributed disk via dedicated LSF queue

## Distributed Disk: CatWeb

**88 Tb**

## PHOBOS: Soon

- Condor to replace LSF batch
- Pros:
-  Free (LSF costs big bucks)
-  Grid-ready
-  PROOF-ready
- Cons:
- No “queue” concept (hackish solutions may exist)

## PHOBOS: Soon

- PROOF (Parallel ROOT Facility)
-  Brings the process to the data!
-  In use now on pharm, soon on RCF
- Hooks in with Condor (specifically: Condor On Demand, preempting all other activity)

## PROOF in action

- root

- Remote PROOF Cluster

- Local PC

**$ root**

- node1

- node2

- node3

- node4

**$ root**
**root [0] tree.Process(“ana.C”)**

**$ root**
**root [0] tree.Process(“ana.C”)**
**root [1] gROOT->Proof(“remote”)**

**$ root**
**root [0] tree.Process(“ana.C”)**
**root [1] gROOT->Proof(“remote”)**
**root [2] chain.Process(“ana.C”)**

- ana.C

- #proof.conf
- slave node1
- slave node2
- slave node3
- slave node4

- *.root

- *.root

- *.root

- *.root