Software status

for commissioning tests

Olivier Deschamps

Calorimeter commissioning meetingCalorimeter commissioning meeting – 14 february 2007 – 14 february 2007

OutlineOutline

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 DBI - Calo readout in condition DB

<condition name = "CellsToCards"> <param name = "PinArea" type = "int" > 3 </param> <param name = "CardArraySize" type = "int" > 8 </param>

<paramVector name = "cards" type = "int"><!--- # a cf rf cl rl cr sl --> 0 0 0 6 7 9 8 1 1 0 0 10 7 13 8 2 2 0 0 14 7 17 8 3… 187 2 32 46 39 49 16 13

<!--- PIN-diode FE --> 188 3 6 23 9 10 11 0 189 3 10 23 13 10 11 1 190 3 40 50 47 53 17 14 191 3 40 54 47 57 17 15 </paramVector>

• 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 DBI - Calo readout in condition DB

<paramVector name = "Tell1" type = "int">

0 7 0 1 2 3 4 5 6 1 6 7 8 9 10 11 12… 6 8 84 85 86 87 88 89 188 189 7 8 90 91 92 93 94 95 96 97… 16 8 112 113 114 115 116 117 118 119 17 8 190 191 120 121 122 123 124 125 18 8 126 127 128 129 130 131 132 133… 25 6 78 79 80 81 82 83

</paramVector> </condition>

• Tell1 description

I - Calo readout in condition DBI - Calo readout in condition DB

<condition name = "MonitoringSystem"> <param name = "PinArraySize" type = "int" > 14 </param> <paramVector name = "PIN" type = "int"><!-- box c pin a cf rf cl rl s cr sl adc cled*rled --> 01 01 04 0 00 50 07 57 0 11 00 00 2 2 02 01 03 0 08 50 15 57 0 11 00 01 2 2 03 01 03 1 08 44 15 51 0 11 00 02 2 2 04 01 15 2 26 20 31 25 0 11 00 03 2 2 03 02 05 1 08 36 15 43 0 11 00 04 2 2 03 03 07 1 08 28 15 35 0 11 00 05 2 2… 08 11 08 1 56 28 63 35 1 17 15 29 2 2 08 12 23 0 40 14 47 17 1 17 15 30 2 1 08 13 19 0 40 18 47 21 1 17 15 31 2 1 </paramVector> </condition>

• Describing the  monitoring system (PIN/LED scheme for Ecal/Hcal)

StatusReady & 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 condDBII - 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 DeCalorimeterCaloPin, CaloLed, CellParam CardParam,Tell1Param (new)

• Also provides many (some new) methods to allow navigation betweenCell <-> FE-Card <-> Tell1PIN <-> 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 III – Decoding Calo rawData

• Tools & algorithm available in LHCb/Calo/CaloDAQ

• Decoding almost transparent for PINs thanks to the ‘virtual’ cell trickDAQ 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 DeCalorimeterBetter sharing of common utilities for readout tools

Status : ready

• Further improvements forseen but not crucial for comissionning tests

IV – Simulating LED dataIV – 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 sequencesFor a arbitrary LED ordering :

Seq1 : fired LED = 0 – 9 – 19 – 29 -….Seq2 : fired LED = 1 - 10 - 20 - 30 -……

Occupancy ~ 1/rate

Status : ready

V- Monitoring & histogramingV- 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 == ‘Oh it Run 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 & histogrammingV- 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 BankoDecode TELL1 with pin-diode readout (e.g. Tell1’s number 6 & 17 for

Ecal)oLoop over Pin-diode ADCso If 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 cellsoDecode 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)

o If Led is fired fill PMT, Pin, PMT/PIN histogramso If Led is not fired pedestal histograms

V- Monitoring & histogrammingV- 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 thresholdIf above : fired cell histogramsIf below : pedestal histograms (downscale rate) Prs & Spd monitoring Allow Ecal/Hcal check independantly of PIN monitoring

V- Monitoring & histogrammingV- Monitoring & histogramming• Histogramming in CaloMoniLed :

Follow framework proposed by the Histograms & monitoring groupUse the standard GaudiHistoAlg base algorithm Use the standard book() & fill() methods (Scenario 1 in EDMS 748834 )

• Several groups of 1D histograms to be produced each group can be enable (disable) by optionsRange & bining also defined by options

• Histograms organization (e.g. for Ecal)Ecal/Fired/ : contain 6016 + 124 histos w/ fired Pmt + Pin signalEcal/Pedestal/ : contains 6016 + 124 histos w/ Pmt + Pin pedestalEcal/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 channelIdid = 2 : Adc/Pin accumulation versus FIRED ChannelIdid = 3 : (Adc/Pin)² accumulation versus FIRED channelIdid = 4-6 : same for pedestal versus channelId

Allow to compute <Pmt/Pin> and spread for all channelsWhen 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 & histogramingV- Monitoring & histograming

500 evts with LED rate = 10%

Analysis ½ (zoom)

Ecal/fired Ecal/pedestal Ecal/ratio

Ecal/summary/1 Ecal/summary/2

Entries PMT/PIN

Timing issueTiming 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 Hz 50Hz 20Hz

Number of Tell1 to be decoded/ sequence 22-25 16-20 9-13

Access RawEvent 0.4 ms 0.4 ms 0.4 ms

+ Process data 1.7 ms 1.3 ms 0.8 ms

+ Fill 3 summary histos 2.1 ms 1.5 ms 1.0 ms

+ Fill all histo (18k) 5.3 ms 2.3 ms 1.4 ms

200Hz global rate + 10% occupancy == 1 kHz with 2% occupancy == 20Hz/cell

5 ms @ 200Hz or 1 ms with 1ms @ 1kHz both fulfills the ‘single CPU constraint’

Timing issueTiming 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 10-20 Hz

fulfill Yuri requirement

VI- Connecting to hardware : commissioningVI- 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 sethbook 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 :

http://lhcb-daq.web.cern.ch/lhcb-daq/meprx/index.html • Stéphane T’Jampens start looking how to produce MDF• Will provide TELL1 data for test soon

VI- Connecting to hardware : commissioningVI- Connecting to hardware : commissioning

• On Orwell side :

• just need few additional lines in main options file to run Orwell on MDFStandard 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)

SummarySummary

• 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

QuestionsQuestions

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 DAQduring commissioning ?

If yes dedicated monitoring is to be developped.

Monitoring system for Ecal/HcalMonitoring 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/EtrueErec/Etrue

Unconverted γs

Converted γsBK* γ

Full events Brunel v17r4

Unconverted γs

Clean γBrunel v15r3

Full eventBrunel v17r4

Left tail due to borders effects, acceptance effects, ADC saturation …

Right tail due to extra energy polluting clusters