LHCb Computing Status Report Meeting with LHCC Referees March 24th, 1999

1
LHCb Computing Status ReportMeeting with LHCC
RefereesMarch 24th, 1999

• John Harvey
• CERN/ EP-ALC

2
Outline

• Status of the LHCb simulation program (SICB)
• News on computing facilities used by LHCb
• GAUDI
• Important milestones since since Oct 1998
• Architecture review
• First release of framework, progress on
  algorithms
• Implementation issues
• Programme of work in 1999 plans for future
  releases
• Training - LHCb OO programming course
• LHCb Software Weeks
• Summary

3
Status of SICB

• Version 117 beginning of March 98
• Infrastructure to plug in any event generator
  (HEPEVT)
• LHC proton beams angles and smearing (trigger
  studies)
• Luminosity handling (multiple interactions per
  beam crossing)
• Updated geometry for Muon Detector and shielding
• Magnetic Field Map for new conical magnet design
  (CERN)
• Field less uniform - study impact on m trigger
  and tracking
• Port to Windows NT completed
• production environment setup on PCSF, still being
  optimised
• 100 k events simulated since beginning of March
• can produce 50k events per day

4
SICB - plans for future releases

• New b-decay generator will be integrated (QQ
  package - CLEO)
• New vertex detector layout (27 stations, 4 f
  sectors) - for late 1999
• RICHes
• Improve fast parameterization (no background, no
  pattern recognition)
• Full digitization and pattern recognition - study
  extended tracking and CPU needs
• Calorimeters
• Projective geometry for Preshower, ECAL and HCAL
• More accurate GEANT Simulation - lower thresholds
  and full sampling
• New trigger code 2x2 algorithm and 3x3
  algorithm in the 4/12 scheme
• Muon Trigger background - showering in m
  shielding and neutron capture
• New beam pipe design

5
Computing Facilities

• Monte Carlo production
• PCSF (CERN) - NT
• IN2P3/ Lyon - UNIX
• RAL - UNIX and NT
• Collaboration facilities
• Liverpool - 300 node PC/Linux farm under
  development
• Rio - PC/Linux farm
• Moscow - PC/Linux farm
• Analyses use public batch facilities at CERN
  (RSPLUS)
• must envisage private capacity (SHIFT) in 2000

6
LHCb Offline Software Road Map
Integration and Commissioning
Exploitation
Detailed Implementation
Release Number
Working Prototype, retire SICB
2004
2002
2000
2006
7
Strategy for development of new software

• We are convinced of the importance of the
  architecture
• architect (experienced designer) and design team
  (domain specialists)
• Identify components, define their interfaces,
  relationships among them
• Build framework from implementations of these
  components
• framework is an artefact that guarantees the
  architecture is respected
• to be used in all the LHCb event data processing
  applications including high level trigger,
  simulation, reconstruction, analysis.
• Build high quality components and maximise reuse
• Incremental approach to development
• new release every two months
• gradually add functionality
• use what is produced and get rapid feedback

8
Important Milestones since Oct 98

• Sept 98 - architect appointed and software
  design team
• Nov 25 - Review of LHCb software architecture
  (GAUDI)
• agreement on components to be implemented in
  version 1
• Dec 7-11 - First LHCb course in OO Analysis
  Design
• Jan 18-22 - Second LHCb course in OO Analysis
  Design
• Feb 5 - Release of first version of GAUDI
  framework
• Feb 8-12 - First LHCb Software Week
• Work programme agreed for version 2 of GAUDI
• Five new members of the GAUDI team to tackle next
  phase

9
Architecture Design
GAUDI General Architecture for Unified Data
Interfaces
10
LHCb Software Architecture - GAUDI
11
Major Design Criteria

• Clear separation between data and algorithms
• Three basic types of data
• event data
• detector data (structure, geometry, calibration,
  alignment,..)
• statistical data (histograms, )
• Clear separation between persistent and
  transient data
• Isolation of users code
• Different/incompatible optimization criteria
• Transient as a bridge between various
  representations
• Data Store centered architectural style
• Algorithms as data producers and consumers
• User code encapsulated in few specific places
• Algorithms Physics code
• Converters Converting data objects into other
  representations

12
Classification of classes
13
Architecture Review

• Review took place on Nov 25th with external
  reviewers
• Were goals met?
• Force preparation for the review - Documentation!
• This was done - all documents available via web
• Validation of the requirements
• many use cases evaluated
• Evaluate early before it becomes a blueprint
  for software
• Determine where finer grain depictions needed
• document global knowledge, object relationships
  are a problem, monitoring state of application
  must be envisaged, .
• Disseminate ideas on what constitutes a good
  architecture
• very positive feedback from ATLAS, STAR,
• Determine whether can proceed to development
• YES - deliver something to end users - be
  prepared to redesign parts

14
GAUDI Framework Status

• Version 1.0 was released on Feb 5th
• Level of functionality provided
• Application Manager is complete
• Event data service allows existing SICB events to
  be read
• Transient event data service allows events to be
  viewed within a C framework and an OO LHCb
  event model
• Histogram data service create, store, retrieve
  histograms
• Histogram persistency service only HBOOK data
  files so far
• Implementation of basic services Job Options,
  Message,
• Composed of
• Libraries (WNT 4.0, IBM AIX 4.1.5 4.3, HP-UX
  10.20, Linux RedHat 5.1)
• Example code
• Documentation User Guide, Reference Manual
• URL http//lhcb.cern.ch/computing/Components/html
  /GaudiMain.html

15
Algorithms

• RICH detectors
• Goal - re-implement the existing pattern
  recognition algorithms in OO
• Complex problem - good test
• Model radiators, mirrors, detectors tracks,
  pixels, photons
• OO design made, implementation to be completed
  soon
• Compare with FORTRAN algorithm
  understandability, cpu usage.
• Next stepsintegrate with GAUDI
• Muon detector
• take relatively simple piece digitisation
• make complete analysis, design and code
• design made, implement and test soon
• repeat procedure for reconstruction and trigger
• First ideas presented on Tracking, Calorimetry
  and Analysis

16
Implementation Issues

• Packages
• Runtime libraries
• Visual Developer Studio on NT
• Code repository - CVS
• Access to code repository from NT - WinCVS
• C coding conventions (LHC common project)
• specification document to be finalised soon
• code check utility to verify rules (36 rules
  coded so far)
• Software Release Tool
• currently use CMT (Orsay)
• following progress of SPIDER/SRT project
• Documentation tool

17
Physical design - Packages

• For large software systems is important to
  decompose into hierarchies of smaller more
  manageable entities.
• The physical decomposition has big consequences
  on compilation time, link dependencies,
  configuration management, executable size, etc.
• Need a macro unit of physical design referred to
  as a package
• Follow rules - avoid cyclic dependencies

k
l
Level 2
Package Level 2
i
j
Level 1
Package a
DependsOn
f
g
h
a
Package Level 1
b
c
d
e
Package b
18
Package Structure
Level 4
Applications
(examples)
Algorithms
SicBxx
Detector DB
Level 3
SicBxx
Algorithms
SicbCnv
LHCb
(converters)
(converters)
Algorithms
HbookCnv
Level 2
LHCbDetector
LHCbEvent
(converters)
Level 1
Gaudi
Package group
Package dependency
19
Next version of GAUDI

• Consolidate what weve done
• Improvements to algorithm interface, histogram
  interface, message level handling, . ..
• Need to validate critical design decisions (e.g.
  the separation between transient and persistent
  data ), for example by measuring impact on
  performance
• Start adding new components
• Libraries
• study what exists (NAGC, clhep, STL,)
• make recommendations and guidelines
• Detector description and geometry - a generic
  model plus subdetector specifics
• Writable storage to be able to store results
• solutions are ROOT I/O (now), Objectivity(later)
  
• Visualization and interactivity
• The candidate solutions are ROOT, WIRED/JAS
  (Java), Open Scientist (OpenGL, OpenInventor,)
• We will integrate these 3 solutions with the
  Gaudi Framework and evaluate

20
Software Work Programme in 1999
End Aug
End Nov
End May

• GAUDI
• detector geometry
• writable storage
• data selectors
• visualisation
• DETECTOR SPECIFIC
• detector description
• RECONSTRUCTION
• pattern recognition
• adapt to detector description
• SIMULATION
• install/evaluate GEANT4
• detector description in GEANT4
• detector response algorithms
• ANALYSIS
• analysis tools
• TESTBEAM
• integrate RIO, detector geometry

21
LHCb OO Programming Course

• Five day course held at CERN Dec 7-11, Jan 18-22
• Covers OO Analysis and Design, and hands-on
  programming
• Establish use of common methods and notation
• 16 people per course, total of 40 now trained
• Now added to CERN OO training curriculum

22
Agenda for First Software week
Software weeks in 1999 planned for June 2-4, Nov
24-26
23
Summary

• First version of new GAUDI framework available
• Development of pattern recognition algorithms
  using GAUDI
• waiting feedback, new ideas, adapt as required
• New components being added which will allow GAUDI
  to be used as a real reconstruction and analysis
  tool
• Start projects for each application program
• starting with reconstruction
• project leader to organise regular working
  sessions as required

24
Practical Experience (Niko Neufeld)

• Importance of books, training, trial and error
• Tools - powerful but complex (Rose)
• Libraries - NAGC, clhep, STL
• Steep learning curve - spend lot of time in
  analysis design
• Reuse existing solutionsdesign patterns

25
DAQ Status - Outline

• Requirements and Architecture, TP numbers,
  review, workshop, update
• Readout Network
• problem statement
• assembling large networks from small switching
  components
• recovery of scalability - traffic shaping,
  intermediate buffers
• strategy and plans - type of control,
  configuration size, calculation, simulation
• prototypes
• Readout Unit - describe prototype design
• SFC - use of intelligent network interfaces
• Myrinet studies
• results from prototype
• results from simulation
• Studies of Gbit ethernet and SCI planned or
  underway
• TFC - status of technical note - missing manpower
  still
• JCOP - concerns about SCADA project