ALICE Off-line Overview

1
ALICE Off-line Overview
Federico Carminati CERN - ALICE April 8, 2000
2
ALICE in numbers

• Beams
• Initially 208Pb208Pb, pp, other masses
• Luminosity
• L02 1027 cm-2 s-1 (PbPb at lt6TeV/n)
• Event rate
• 16000 s-1 min bias, 50-100 s-1 central collisions
• Data taking
• 10 per LHC year (106 sec/y), few 107 central
  events
• Charged multiplicity
• (dN/dy)ch2000-8000

3
ALICE in numbers

• Raw data rate
• 1.25 GB/s (compressed)
• Raw data size
• 80 MB/event (zero suppressed)
• Computing needs
• gt2000kSI95 estimated need
• 2PB of raw data (protonions) 2PB of derived
  and/or simulated data
• 500TB of disk at CERN, 300 at the regional
  centres

4
The ALICE Detector
5
The ALICE Collaboration
900 physicists and engineers, 26 countries, 70
institutes
6
ALICE Off-line beg98

• Small(er) (LHC) collaboration
• Cannot afford several development lines (read my
  lips)
• Must reuse code
• Software and Physics are one single group
• Use programs available and working now
• Minimise the legacy-code-to-be
• IT/LCB/RD official line was not ready
• Only working framework FORTRAN ZEBRA PAW
• Users were not (yet all) speaking OO
• Split into dinosaurs, prophets and lost
  users

7
The LHC Computing Challenge
Design the Detectors and Prepare the Code Now
Design the New Software Framework
Train and Involve the User Community
8
ALICE event/100
9
Are we in trouble with Simulation?

• Simulation is vital, but
• Using GEANT 3.21
• Stay with FORTRAN, shaky physics and geometry
• Using GEANT 4
• Fresh from the oven can we trust it yet?
• Using FLUKA
• Difficult to use, limited geometry

10
ALICE's choice

• Migrate immediately to C
• Therefore immediately abandon PAW
• But accept GEANT3.21 (initially)
• Adopt the ROOT framework
• Not worried of being dependent on ROOT
• Much more worried being dependent on G4, Objy....
• Allow use of FORTRAN and C
• Allow to start with wrapping and bad design
• Impose a single framework
• Provide central support, documentation and
  distribution
• Train users in the framework

11
(No Transcript)
12
Comparison F77/C

• Time per event
• Old link gt40 run 710/event (11h50m)
• New link lt1 run 435/event (7h15m)
• Space
• Old galint executable 11MB
• New AliRoot executable 438kB
• Documentation
• Old Web page (by hand!)
• New in the code and automatically extracted

13
Tracking schema
FLUKA Step
Module Version StepManager Add the hit
GUSTEP
Geant4StepManager
Disk I/O Root
14
(No Transcript)
15
GEANT 4

• Large effort
• Two people since two years
• We did not sign the famous MOU
• which is going to disappear anyway
• A lot of surprises
• almost all of them bad
• Strong commitment to test and try using it
• See talks later

16
FLUKA at LHC

• Used by all LHC experiments for radiation
  calculations and single detector response studies
• ALICE has officially requested at CERN support
  for FLUKA, and this has been promised
• Under these conditions a source release can
  intervene in few months

17
NASA collaboration

• NASA
• has adopted ROOT as framework
• is increasingly interested in transport
  MonteCarlos for radiation safety in deep flight
  space missions
• is very interested in the physics of FLUKA and in
  the ALICE VirtualMonteCarlo
• They decided to fund 1.5 FTE for 3 years
• Interface with AliRoot
• Improve Ion transport capabilities
• TFLUKA is born!

18
ALICE's policy

• We follow a minimum resistance path
• Use ROOT polymorphic containers
• Use a java-like subset of C
• Discourage templates and STL
• Completely rely on CINT (I/O, script interpreter)
• Do not use CLHEP, LHC or alternative
  components
• Not worried by all-out modularity
• Official request to CERN management
• Support for ROOT
• Consider it for the choice of a common LHC
  solution
• Consider it in the development of new solutions

19
(No Transcript)
20
(No Transcript)
21
Cathedrals and Bazaars

• Definitely a Bazaar model
• Rapid prototyping, rapid response to user
  feed-back
• Use extensively prototyping
• Existing technology
• Production code
• Design only what you can prototype
• do not hope in technological miracle
• Development based on
• micro cycles
• macro-cycles

22
(No Transcript)
23
The ALICE Mass Storage Project

• Close collaboration with CERN/IT
• Assess our computing model in realistic
  conditions
• Develop integration DAQ and Off-line and event
  model
• Provide a framework to assess new technologies
• MSS situation confused
• Enstore, CASTOR, HPSS IBM, Eurostore I
• Participation into Eurostore II
• EU financing, proposal submitted to Jan 15 call
• CERN, DESY, QSW, Tera
• We will interface ROOT with Eurostore II

24
(No Transcript)
25
Results

• Grand Total after 7 days of running
• Number of files 15,436
• Number of events 16,229,520
• Mbytes in 7,261,382
• Mbytes out 6,896,198
• Aggregate rate in (MB/s) 14.7
• Aggregate rate out (MB/s) 13.9
• Total stored to HPSS 6.9 TB
• Was one of the largest OO DBs in HEP

26
ALICE DC II
NA 57 data source
Computer Centre
9 PowerPC AIX
LDC
LDC
5 MB/s
LDC
Intel/Linux PC Cluster 10/15 nodes
LDC
LDC
LDC
LDC
Switch
LDC
LDC
GB eth
GDCEvent Builder
pipe
Switch
ROOTObjectifier
Intel/PC Linux PowerPC /AIX Sun
Switch
LDC
LDC
LDC
10MB/s GB eth
LDC
LDC
LDC
LDC
LDC
10 MB/s
HPSS
CASTOR
Eurostore II
LDC
ALICE DAQ data source
DATEGDCLDC
27
(No Transcript)
28
Persistencythe dream (P.Sphicas CHEP2000)

• The database should make access to data anywhere
  at any time transparent and efficient
• Data should be accessible at the object level at
  any stage
• The database should optimise data access patterns
  used by the users
• The MSS/HSM should be transparent to the users

29
PersistencyReality Check

• The OODBMS market is not taking off
• The only candidate is from a small company
• Improvements have been poor in 5 years
• In fact only doubts have grown
• Tests up to now are not conclusive even for
  simple local use
• BABAR just managed - and at a price
• MSS/HMS do not seem to match Objy
• More important than all Do we need it?

30
(No Transcript)
31
ROOT Objectivity Test

• Tests
• Read the data produced with AliRoot and write
  them into an Objectivity DB
• Random read 1, 10 50 and 100 of one event
• Local test - no Objy server
• Lesson learned
• Co-operation of the two system is possible and
  relatively simple to set-up
• Naïve use of ROOT simple and robust
• Naïve use of Objectivity impossible, some of the
  features are hardly understood by the experts
  (Jul 1999)
• RT/size performance of ROOT superior to
  Objectivity

32
ALICE's position

• We have evaluated Objy and we do not see any
  reason to consider it
• We need a finer control of the functionality of
  the database
• We need an effective tool to perform parallel
  distributed analysis
• Possibly exploiting the GRID middleware

33
(No Transcript)
34
The PROOF system
Slave 1
Slave N
Master
Tree-gtDraw()
Tree-gtDraw()
Initialisation
Initialisation
GetNextPacket()
GetNextPacket()
0,100
Process
100,100
Process
GetNextPacket()
GetNextPacket()
Packet Generator
200,100
Process
300,40
Process
GetNextPacket()
GetNextPacket()
340,100
Process
Process
440,50
GetNextPacket()
GetNextPacket()
490,100
Process
590,60
Process
GetNextPacket()
SendObject(histo)
Wait for next command
Add histograms
Wait for next command
Display histograms
35
Software Development

• Simple minded cvs server
• Soon evaluation of configuration management tools
• Use of a ALICE and ROOT aware coding convention
  checking tool
• Evaluating a restriction of the C syntax
• Make it a simpler language
• Do not diverge too much from Java
• Development of an ALICE and ROOT aware reverse
  engineering tool

36
Geometrical DB

• The big lost occasion of Geant4
• Should be the same for all applications
• Visualisation, simulation, reconstruction,
  monitoring, fast simulation, event display
• Possible common project with the other
  experiments
• Project with CRS4/Cagliari will be started soon

37
(No Transcript)
38
Lesson (re)Learnt

• Users are ready to move to OO if there is
• A clear framework and a path to it
• Support and consultancy for new users
• Training targeting the framework
• Some flexibility toward FORTRAN inclusion
• People are afraid to be unproductive for a long
  time or to waste their work
• Many old FORTRAN users provide their
  contributions
• Remote users contribute once a framework is
  decided
• A mutual trust relationship has to be built

39
Open Problems Perspectives

• CERN socio-political-technical situation
• Is the Hoffmann review an opportunity for a
  solution
• or is it part of the problem?
• PersonPower!
• Areas of development
• Detector databases (including Geometry)
• Visualisation
• Event model
• Data processing / analysis / World computing
  model
• Configuration management
• Global reconstruction
• MSS/HSM