Brunel status and plans

1. 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 10000 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. Transient Event Data EventSelector /Event /MC SpilloverSelector /MCNext /MCNextNext xxDigi /MCPrev /MCPrevPrev /Raw /Rec SpilloverSelector.TimeOffsetNext = 25*ns; SpilloverSelector.TimeOffsetNextNext = 50*ns; SpilloverSelector.TimeOffsetPrev = -25*ns; SpilloverSelector.TimeOffsetPrevPrev = -50*ns; Spillover events in Gaudi • SpilloverSelector in next Gaudi release (November 1st) • First xxDigi: tracking

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 Conventionshttp://lhcb.cern.ch/computing/Reconstruction/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 • http://lhcb.cern.ch/computing/offline/html/minutes20000828.htm • http://lhcb.cern.ch/computing/offline/html/minutes20000911.htm • 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 const double my_height = 170*cm; // = 1700 const double my_weight = 75*kg; // = 4.68e+26 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. ); 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. MCCalo SummedDeposit MCCalo Deposit MCParticle CaloDigit Attributes Attributes Attributes Attributes Operations Operations Operations Operations MCCaloDigit 1 1 1..N Event Data ModelRelationship between Raw data and MC Hits • Implemented by inheritance:

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

16. TrMeasurement MCParticle TrTrack 2..N MCTrackingHit OTDigi TrTrackMCParticleAssociator 1 Attributes Attributes Attributes Attributes Attributes Operations Operations Operations Operations Operations MCHitBase MCOTDigi OTHit 1 1 Event Data ModelGeneric 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

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

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!