LHCb Computing Status Report Meeting with LHCC Referees March 24th, 1999 John Harvey CERN/ EP-ALC

Report to LHCC Referees March 1999 Slide 2 Outline qStatus of the LHCb simulation program (SICB) qNews on computing facilities used by LHCb qGAUDI ã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 qTraining - LHCb OO programming course qLHCb Software Weeks qSummary

Report to LHCC Referees March 1999 Slide 3 Status of SICB qVersion 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  trigger and tracking qPort 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

Report to LHCC Referees March 1999 Slide 4 SICB - plans for future releases qNew b-decay generator will be integrated (QQ package - CLEO)  New vertex detector layout (27 stations, 4  sectors) - for late 1999 qRICHes âImprove fast parameterization (no background, no pattern recognition) âFull digitization and pattern recognition - study extended tracking and CPU needs qCalorimeters â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  shielding and neutron capture qNew beam pipe design

Report to LHCC Referees March 1999 Slide 5 Computing Facilities qMonte Carlo production ãPCSF (CERN) - NT ãIN2P3/ Lyon - UNIX ãRAL - UNIX and NT qCollaboration facilities ãLiverpool node PC/Linux farm under development ãRio - PC/Linux farm ãMoscow - PC/Linux farm qAnalyses use public batch facilities at CERN (RSPLUS) ãmust envisage private capacity (SHIFT) in 2000

Report to LHCC Referees March 1999 Slide 6 LHCb Offline Software Road Map Working Prototype, ‘retire’ SICB Detailed Implementation Integration and CommissioningExploitation Release Number 2006

Report to LHCC Referees March 1999 Slide 7 Strategy for development of new software qWe are convinced of the importance of the architecture ãarchitect (experienced designer) and design team (domain specialists) qIdentify components, define their interfaces, relationships among them qBuild 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 qIncremental approach to development ãnew release every two months ãgradually add functionality ãuse what is produced and get rapid feedback

Report to LHCC Referees March 1999 Slide 8 Important Milestones since Oct ‘98 qSept ‘98 - architect appointed and software design team qNov 25 - Review of LHCb software architecture (GAUDI) ãagreement on components to be implemented in version 1 qDec First LHCb course in OO Analysis & Design qJan Second LHCb course in OO Analysis & Design qFeb 5 - Release of first version of GAUDI framework qFeb First LHCb Software Week ãWork programme agreed for version 2 of GAUDI ãFive new members of the GAUDI team to tackle next phase

Report to LHCC Referees March 1999 Slide 9 Architecture Design GAUDI General Architecture for Unified Data Interfaces

Report to LHCC Referees March 1999 Slide 10 LHCb Software Architecture - GAUDI

Report to LHCC Referees March 1999 Slide 11 Major Design Criteria qClear separation between “data” and “algorithms” qThree basic types of data: ãevent data ãdetector data (structure, geometry, calibration, alignment,..) ãstatistical data (histograms, …) qClear separation between “persistent” and “transient” data ãIsolation of user’s code ãDifferent/incompatible optimization criteria ãTransient as a bridge between various representations qData Store centered architectural style ãAlgorithms as data producers and consumers qUser code encapsulated in few specific places: ã “Algorithms”: Physics code ã “Converters”: Converting data objects into other representations

Report to LHCC Referees March 1999 Slide 12 Classification of classes

Report to LHCC Referees March 1999 Slide 13 Architecture Review qReview took place on Nov 25th with external reviewers qWere 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

Report to LHCC Referees March 1999 Slide 14 GAUDI Framework Status qVersion 1.0 was released on Feb 5th qLevel 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,… qComposed of: ãLibraries ( WNT 4.0, IBM AIX & 4.3, HP-UX 10.20, Linux RedHat 5.1 ) ãExample code ãDocumentation: User Guide, Reference Manual ãURL:

Report to LHCC Referees March 1999 Slide 15 Algorithms qRICH 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 steps…integrate with GAUDI qMuon detector ãtake relatively simple piece : digitisation ãmake complete analysis, design and code ãdesign made, implement and test soon ãrepeat procedure for reconstruction and trigger qFirst ideas presented on Tracking, Calorimetry and Analysis

Report to LHCC Referees March 1999 Slide 16 Implementation Issues qPackages qRuntime libraries qVisual Developer Studio on NT qCode repository - CVS qAccess to code repository from NT - WinCVS qC++ coding conventions (LHC common project) ãspecification document to be finalised soon ãcode check utility to verify rules (36 rules coded so far) qSoftware Release Tool ãcurrently use CMT (Orsay) ãfollowing progress of SPIDER/SRT project qDocumentation tool

Report to LHCC Referees March 1999 Slide 17 Physical design - Packages qFor large software systems is important to decompose into hierarchies of smaller more manageable entities. qThe physical decomposition has big consequences on compilation time, link dependencies, configuration management, executable size, etc. qNeed a macro unit of physical design referred to as a package qFollow rules - avoid cyclic dependencies kl ij Package Level 2 Level 2 Level 1 fg b ha cde Package Level 1 Package a Package b DependsOn

Report to LHCC Referees March 1999 Slide 18 Package Structure Algorithms Gaudi LHCbDetector SicBxx SicbCnv (converters) Applications (examples) Algorithms LHCb Algorithms Detector DB (converters) LHCbEvent HbookCnv (converters) Package group Package dependency Level 1 Level 2 Level 3 Level 4

Report to LHCC Referees March 1999 Slide 19 Next version of GAUDI qConsolidate what we’ve 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 qStart 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

Software Work Programme in 1999 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 End AugEnd NovEnd May

Report to LHCC Referees March 1999 Slide 21 LHCb OO Programming Course qFive day course held at CERN Dec 7-11, Jan qCovers OO Analysis and Design, and hands-on programming qEstablish use of common methods and notation q16 people per course, total of ~40 now trained qNow added to CERN OO training curriculum

Report to LHCC Referees March 1999 Slide 22 Agenda for First Software week Software weeks in 1999 planned for June 2-4, Nov 24-26

Report to LHCC Referees March 1999 Slide 23 Summary qFirst version of new GAUDI framework available qDevelopment of pattern recognition algorithms using GAUDI ãwaiting feedback, new ideas, adapt as required qNew components being added which will allow GAUDI to be used as a real reconstruction and analysis tool qStart projects for each application program ãstarting with reconstruction ãproject leader to organise regular working sessions as required

Report to LHCC Referees March 1999 Slide 24 Practical Experience (Niko Neufeld) qImportance of books, training, trial and error qTools - powerful but complex (Rose) qLibraries - NAGC, clhep, STL qSteep learning curve - spend lot of time in analysis & design qReuse existing solutions…design patterns

Report to LHCC Referees March 1999 Slide 25 DAQ Status - Outline qRequirements and Architecture, TP numbers, review, workshop, update qReadout 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 qReadout Unit - describe prototype design qSFC - use of intelligent network interfaces qMyrinet studies ãresults from prototype ãresults from simulation qStudies of Gbit ethernet and SCI planned or underway qTFC - status of technical note - missing manpower still qJCOP - concerns about SCADA project