Marco Cattaneo, Milano, 27th September Brunel status and plans Status of commissioning Forthcoming improvements Conventions

2 Verification status  Brunel v1r3 corresponds to SICBDST v235 i.e. Steering, I/O done by Gaudi, reconstruction done by wrapped Fortran algorithms from SICBDST  dst1 and dst2 samples produced with both programs, starting from same RAWH input 100 events DST1 B->pi+pi- 500 events DST2 B->pi+pi-  Outputs compared using new data quality tool (See Agnieszka’s talk) Detailed checks also by many sub-detectors DST1 identical DST2 fully compatible within statistics (pileup in Gaudi uses different random number sequence)  Brunel functionally identical to SICBDST

3 DST1 comparison

4 DST2 comparison

5 Brunel Commissioning  Goal: Use current Brunel version (wrapped SICBDST algorithms) in production INSTEAD of SICBDST  Benefit: New functionality (spillover, tracking) can be verified in production environment, and quickly integrated if physics criteria are fulfilled.  Commissioning plan: Use Brunel v1r3 to produce events on PCSF Adapt scripts, verify program stability vs. SICBDST Status: started last week Packaging and distribution Current Brunel executable uses shared libraries from AFS Produce static linked, self-contained executables for Linux and NT Status: start next week Review status at next software week (1-3 November)

6 Forthcoming improvements (timescale of one month) Infrastructure for Spillover events C++ Track Fit

7 Spillover events  Definitions: Pileup: several events from same beam crossing Combination done by simply adding MC Hits of underlying events to the physics event Requires no changes to digitisation code Implemented in both Brunel and SICB Spillover: events from previous or subsequent beam crossing Combination must preserve 25ns timing offset Digitisation must know what to do with hits that are 25nd early/late  Sub-detector specific Not implemented in SICB or Brunel  I/O for additional events easy with Gaudi  Sub-detector digitisation code must be rewritten (if spillover is relevant)

8  SpilloverSelector in next Gaudi release (November 1st)  First xxDigi: tracking Spillover events in Gaudi Transient Event Data /Event /MC /MCNext /MCNextNext /MCPrev /MCPrevPrev /Raw /Rec EventSelector SpilloverSelector xxDigi SpilloverSelector.TimeOffsetNext = 25*ns; SpilloverSelector.TimeOffsetNextNext = 50*ns; SpilloverSelector.TimeOffsetPrev = -25*ns; SpilloverSelector.TimeOffsetPrevPrev = -50*ns;

9 C++ Tracking  C++ track fit runs in Brunel now Comparison possible (in Gaudi) between Fortran and C++ fits Similar results  By end October: Feed fit results back to AXTK  Links to RAWH? Possibility to abandon Fortran track fit in production version First release of pattern recognition Probably not yet production quality, BUT Pattern recognition results available (in AXTK) for private studies by other sub-detectors

10 SICBDST retirement  By 1st November it should be possible to: Run current Brunel version in production, on Linux and NT Identical algorithms as SICBDST, different steering main program Optionally, AND if required by the physics groups: Use C++ track fit in production INSTEAD of Fortran track fit Begin studies of effect of pattern recognition Begin studies of effect of spillover events  Can we use Brunel.exe instead of SICBDST.exe in official productions as from November? In a configuration to be decided by physics meeting Subject to fulfilment of commissioning plan

11 Brunel Conventions  Conventions needed for: Uniformity Maintainability  Request at last software week: Proposals to come from Brunel manager  Current proposals: Discussed and approved at computing meetings   Mandatory after today for code accepted into Brunel But review always possible!  Conventions on: Physical Units Event Data Model Access to MonteCarlo truth

12 Physical Units All quantities in Gaudi data stores shall conform to the CLHEP system of units. All dimensioned quantities shall be defined by multiplying by the units in CLHEP/Units/SystemOfUnits.h : Output of dimensioned quantities shall be converted to the required units by dividing by the units in CLHEP/Units/SystemOfUnits.h Physical constants should not be defined in LHCb code. They should be taken directly from CLHEP/Units/PhysicalConstants.h my_hist = histoSvc()->book( "/stat/diet", "corpulence (kg/m**2)",30,10.,40.); double my_corpulence = my_weight / (my_height*my_height); my_hist->fill( my_corpulence/(kg/m2), 1. ); const double my_height = 170*cm; // = 1700 const double my_weight = 75*kg; // = 4.68e+26 float my_rest_energy = my_weight * c_squared;

13 Event Data Model  Glossary MC Event: output of the event generator step.  e.g. MC Particles and MC Vertices MC Hits: output of the GEANT tracking step.  e.g. detector entrance and exit point, energy loss etc. FE data: simulated output of the detector front end,  as seen by the hardware triggers, when different from Raw data. Raw data: output of the digitisation step of the detector simulation, and output of the data acquisition system for real data.  e.g. ADC and TDC counts. Coordinates: output of reconstruction program when applied to detector hits.  e.g. hit coordinates, calorimeter clusters etc. (is there a better name?) Reconstructed data: final output of the reconstruction program.  e.g. tracks, particle ID, energy flow objects etc.  Naming convention Agree on basic names. E.g. CaloDigit and OTDigit.  To be extended, please send me requests.... MC classes that derive from a real data base class have the same name as the base class, prefixed by "MC”. E.g. MCCaloDigit

14 Event Data Model Relationship between Raw data and MC Hits MCParticle Attributes Operations MCCaloDigit MCCalo SummedDeposit Attributes Operations 1 MCCalo Deposit Attributes Operations 1..N CaloDigit Attributes Operations 1  Implemented by inheritance:

15 Information Track segments Reconstructed space points Track candidates Monte Carlo Raw data Hits Digits Particles Dis-integrated Detector response Processing Comparison Generic Data-MC comparison

16 Event Data Model Generic relationship between reconstructed data and MC Hits No other explicit links between reconstructed data and MC truth Navigation always by associator tool in dedicated monitor algorithms Associators may save their AssociationTables to persistent storage to optimise subsequent analyses  Transparent to applications MCParticle Attributes Operations MCTrackingHit Attributes Operations TrTrack Attributes Operations 1 OTHit TrMeasurement Attributes Operations MCOTDigi OTDigi Attributes Operations N MCHitBase TrTrackMCParticleAssociator

17 Associator example: CaloDigitMCSumDepAsct IAssociator* pAsct; std::string m_asctCalo = "CaloDigitMCSumDepAsct"; StatusCode sa = m_toolSvc->retrieveTool( m_asctCalo, pAsct ); for(CaloDigitVector::iterator it=Digs->begin(); Digs->end()!=it; ++it ){ MCCaloSummedDeposit* pMC = 0; StatusCode sas = pAsct->retrieveDirect( *it, pMC ); } CaloClusterCaloDigitPair CaloDigit MCCaloSumDeposit MCCaloDigitMCCaloDepositMCParticle SmartDataPtr Digs(eventSvc(),"/Event/Raw/Ecal/Digits_0");

18 Conclusions  Current Brunel version gives identical results to SICBDST  We could decide NOW to use Brunel for production As soon as it is packaged for production enviroment  Would allow rapid deployment of new features In particular, tracking improvements  Brunel now mature We must adopt conventions

19 Let’s take the plunge!