Software status for commissioning tests Olivier Deschamps Calorimeter commissioning meeting – 14 february 2007

Outline 1.Describing the Calo readout scheme in condDB 2. Accessing the condDB 3. Decoding Calo rawData 4. Simulating Led Data 5. Monitoring and histograming 6. Connecting to hardware : commissioning 7. Summary & Questions

I - Calo readout in condition DB … Already described in Calo(soft) meetings  Brief summary FE-cards description (including PIN-diode FE-cards) DBase/XmlCondition/DDDB/Conditions/Ecal/ReadoutConf/Main.xml Define a virtual cell (with CaloCellID) for each pin PinArea = 3 (inner=2/middle=1/outer=0) - Nice trick for many simplifications in readout

I - Calo readout in condition DB … … … Tell1 description

I - Calo readout in condition DB … Describing the monitoring system (PIN/LED scheme for Ecal/Hcal) Status Ready & checked for Ecal Monitoring system to be implemented for Hcal (I have all inputs from Yuri) For comissionning test : will need to implement the actual scheme

II - Accessing the condDB All accesses to condDB centralized in the Detector Element LHCb/Det/CaloDet Readout scheme decoded in the initialization of CaloDet BuildCells()from xmlDDDB (Detector Description) BuildCards()from condDB BuildTell1s()from condDB BuildMonitoringSystem()from conDB C++ objects describing the caloReadout can be accessed via DeCalorimeter CaloPin, CaloLed, CellParam CardParam,Tell1Param (new) Also provides many (some new) methods to allow navigation between Cell FE-Card Tell1 PIN LED cells All what is needed for the readout & monitoring of PMT & PIN signals Status : ready for comissioning test Beyond comissioning test : update Manager for condDB to be implemented

III – Decoding Calo rawData Tools & algorithm available in LHCb/Calo/CaloDAQ Decoding almost transparent for PINs thanks to the ‘virtual’ cell trick DAQ produces standard CaloADCs for PIN to be used as normal data Now handle ‘floating’ FE-Cards (pin-diode FE’s that disappears with normal data) Readout tools modified to allow decoding a single Tell1  no need to decode full Calo for monitoring (speed-up)  also useful for Trigger group (fast L0-confirmation) Include debug tools : Possible event dump printout during decoding (Tell1/FE-Card/ADC channel/ADC valiue) Check consistency with condDB description during readout e.g. check FE-card content for TELL1  produce warning in case of inconsistency  Useful for initial tests/debuging during comissionning Several technical improvements added Own FE-card description (with condDB access) merged w/ DeCalorimeter Tell1 description moved to DeCalorimeter Better sharing of common utilities for readout tools Status : ready Further improvements forseen but not crucial for comissionning tests

IV – Simulating LED data Useful for checking readout and developing monitoring algorithms No need for a detailed simulation Minimal modification of Boole set-up - run over some SIM file (no matter the event type) - remove all MCHits (NodeKiller)  so all sub-detector will only produce noises add a trivial algorithm producing LED signal (CaloPinDigit) - random gaussian distribution (mean ADC and sigma by options) - add Led signal to corresponding PMT’s and PIN-diode - pedestal from standard CaloDigit algorithm Trivial ‘cyclic’ LED firing sequence (not realistic but no matter) - LED firing rate can be defined by options - e.g. LedRate = 10; means each LED is fired every 10 sequences For a arbitrary LED ordering : Seq1 : fired LED = 0 – 9 – 19 – 29 -…. Seq2 : fired LED = … …  Occupancy ~ 1/rate Status : ready

V- Monitoring & histograming Proposition for the Calibration Farm project : ORWELL The most adequate naming I found for a Farm Role : control the good behaviour of the farm citizens  Main executable Orwell.exe in package BigBrother/Orwell  standard GaudiApplication Several animals can run in the Orwell’s farm  grouped in the directory Animals/  so far a single animal is foreseen (no revolt) : Calo  package Animals/CaloAnimal contains the Calo histogramming algorithms Moreover, an acronym can been set : Orwell == ‘ O h it R un Well !’ A new LHCb project has been built Contains the online tasks to be executed in the Calibration Farm The most important issue was to find a NAME for the project LHCb usage : adopt celebrity name e.g. Moore (EFF tasks), Brunel (offline reco), … Usualy scientists but not necessary e.g. Panoramix, Bender project dependency : LHCb/ (use Event/DigiEvent, Det/CaloDet, Calo/CaloDAQ, LHCbKernel, …) Online/ (use DAQ/MDF for TELL1 readout - provided by the online group)

V- Monitoring & histogramming Calo monitoring algorithms in Animals/CaloAnimals CaloMoniLed.cpp algorithm : Pin monitoring of LED data (Ecal/Hcal) oGet rawEvent & point to Ecal (or Hcal) packed Bank oDecode TELL1 with pin-diode readout (e.g. Tell1’s number 6 & 17 for Ecal) oLoop over Pin-diode ADCs oIf ADC > threshold  the PIN is fired (threshold by option) oThen look for connected LED’s (1 LED among 2 or 4 is possibly fired) oFind which LED in the group is fired : oFor each led in the group look to the associated group of cells oDecode the corresponding TELL1 (if not already decoded) oSome channels may be dead : look for several channels to decide whether the LED is fired or not (number of test channels in options) oIf Led is fired  fill PMT, Pin, PMT/PIN histograms oIf Led is not fired  pedestal histograms

V- Monitoring & histogramming Fast algorithm (timing issue discussed in few slides Pedestal is only looked on non-fired LEDs associated to fired PIN  Same rate as fired cell  Possible additional downscale rate for ped. set by options(speed up) No need to decode all banks : decode only TELL1 containing fired cells If a Pin-diode channel is dead :  corresponding group of cells will be missing in histograms monitoring  possibility to check if all expected pin-diode are actually fired  require the LED firing sequences to be available in condDB A second trivial algorithm independent on PIN monitoring (still to be written) Decode all ADC & compare to a threshold If above : fired cell  histograms If below : pedestal  histograms (downscale rate)  Prs & Spd monitoring  Allow Ecal/Hcal check independantly of PIN monitoring

V- Monitoring & histogramming Histogramming in CaloMoniLed : Follow framework proposed by the Histograms & monitoring group Use the standard GaudiHistoAlg base algorithm Use the standard book() & fill() methods (Scenario 1 in EDMS ) Several groups of 1D histograms to be produced each group can be enable (disable) by options Range & bining also defined by options Histograms organization (e.g. for Ecal) Ecal/Fired/ : contain histos w/ fired Pmt + Pin signal Ecal/Pedestal/ : contains histos w/ Pmt + Pin pedestal Ecal/Ratio/ : contains 6016 histos w/ Pmt/Pin ratio when fired Histogram id = CaloCellID::Index (14 bits word : area || col || row ) Corresponding cell position appear in histo title. Ecal/Summary/ : contains few histos (6 foreseen) id = 1 : Number of Entries versus FIRED channelId id = 2 : Adc/Pin accumulation versus FIRED ChannelId id = 3 : (Adc/Pin)² accumulation versus FIRED channelId id = 4-6 : same for pedestal versus channelId Allow to compute and spread for all channels When we are convinced the monitoring works well it would be the only set of histo to be produced  don’t produce continuously the huge amount of histos ??

V- Monitoring & histograming 500 evts with LED rate = 10% Analysis ½ (zoom) Ecal/fired Ecal/pedestal Ecal/ratio Ecal/summary/1Ecal/summary/2 Entries PMT/PIN

Timing issue Rough study of timing performance Beyond the scope of the commissioning test Use the ‘cyclic’ Led firing sequences implemented in Boole Speed almost linear with detector occupancy Led fired per sequence ( == occupancy)10%5%2% Cell firing rate (assum. global rate = 1kHz)100 Hz50Hz20Hz Number of Tell1 to be decoded/ sequence Access RawEvent0.4 ms + Process data1.7 ms1.3 ms0.8 ms + Fill 3 summary histos2.1 ms1.5 ms1.0 ms + Fill all histo (18k)5.3 ms2.3 ms1.4 ms 200Hz global rate + 10% occupancy == 1 kHz with 2% occupancy == 20Hz/cell 5 200Hz or 1 ms with 1kHz both fulfills the ‘single CPU constraint’

Timing issue A 20Hz firing rate for individual cell could match the ‘single CPU constraint’ But this is for Ecal ADC only Want to monitor the trigger 8 bits ADCs (?) should be fast : decoded in the same banks than 12 bits ADCs another 18k histos ??  Few summary histos Need to add Hcal : faster than Ecal only 8 Tell1s & RawEvent already loaded And Prs/Spd :simpler processing On the other hand there is some room of improvements to speed-up the monitoring - technical improvement in decoding - set-up a smart LED firing sequence (LED trig board PGA) to minimize the number of Tell1 to be decoded (to be set-up)  Should be OK to run on a single CPU with a reasonable rate/cell of Hz  fulfill Yuri requirement

VI- Connecting to hardware : commissioning Assume we’ll perform ‘offline’ analysis of commissioning data : Store Tell1 outputs Run Orwell on those data Store histograms on disk root file : 8 Mo for 18k histos with the (reasonable) binning I set hbook file also possible : 17 Mo on disk require a bit of time to convert to hbook at finalize() No need to set-up the full online machinery (on-fly data acquisition, histo publishing via DIM protocol and PVSS display …) but could be nice to try to set-up a full online acquisition if we have time Tell1 acquisition discussion with Velo people that did the exercise for ACDC test Online group provide Gaudi applications to capture TELL1 output available in Online/OnlineTasks write in MDF binary format Instruction can be found in : Stéphane T’Jampens start looking how to produce MDF Will provide TELL1 data for test soon

VI- Connecting to hardware : commissioning On Orwell side : just need few additional lines in main options file to run Orwell on MDF Standard Root data : EventSelector.Input = { "DATAFILE=‘myFILE.raw' TYP='POOL_ROOT' OPT='READ'" }; MDF data : ApplicationMgr.DLLs += { "MDF" }; EventPersistencySvc.CnvServices = {"LHCb::RawDataCnvSvc"}; EventSelector.Input += {"DATA='rfio:///Castor/Path/myFile.mdf' SVC='LHCb::MDFSelector'"}; Convert MDF  rawEvent available on TES Try to run Orwell on Velo ACDC mdf files (available on Castor) Correct behaviour : rawEvent produced correctly CaloBank not found in Velo data !! Possibility I go to LAPP during next soft. week (in 2 weeks) work with Stephane to install software environment (Orwell) & test CaloDAQ/Orwell on true TELL1 output (pre-comissionning test)

Summary All pieces of software essentially in place Full chain ready and checked for Ecal To do : complete for Hcal : similar to Ecal – just need condDB update Prs/Spd : no PIN – trivial monitoring to be implemented. Pre-commissioning test at LAPP foreseen by end of february Software not yet in CVS but could be commited now Would be nice if people can have a look to be sure the monitoring provide all what we will need for commissioning test Documentation to be provided

Questions Questions : Would be useful to have some ‘kumacs’ for automatic analyse of the huge amount of histograms Very similar to histo analyzer to be displayed Online Is there volunteer ? Kirill ? What PC will be available for test ? Gaudi environment installed ? Connection to upload and install package ? Panoramix is there volunteer to look at Calo event display for commissioning Do we want to acquire consecutive events (Time alignment event) through DAQ during commissioning ? If yes dedicated monitoring is to be developped.

Monitoring system for Ecal/Hcal CELL-LED-PIN scheme 124 PIN-diodes 456 LEDs 1 PIN handles 2x2 or 1x2 LEDs 1 LED fire 4x4 or 3x3 cells 4 special FE-boards handle LED signals 4 FE-boards  2 TELL1 together with other ‘normal’ data FE-boards (crates 11 & 17) (Ecal-right)

Energy resolution (DC04) Erec/Etrue Unconverted γs Converted γs B  K* γ Full events Brunel v17r4 Unconverted γs Clean γ Brunel v15r3 Full event Brunel v17r4 Left tail due to borders effects, acceptance effects, ADC saturation … Right tail due to extra energy polluting clusters