1. Laboratoire de l’Accélérateur Linéaire, Orsay, France and CERN Olivier Callot 18 March 2003 Online Data Format and Condition Database Proposed data format In the FE crate After zero suppression ECAL-HCAL Prs-Spd Use of the Condition Database

2. Olivier Callot 18 March 2003Online Data Format and Condition Database2 Online Data Format  I have an unpublished Note From March 2001, never published It should be after we agree on the format ! This was probably presented at some meeting but I haven’t found when Sorry for that !  The format in the FE crate is well defined 21 bits are transported from FE card to the CROC 20 bits of data plus a parity 12 (ADC) + 8 (Trigger) for ECAL and HCAL 2*( 8 (ADC) + 1 (Prs trigger) + 1 (SPD) ) for PreShower

3. Olivier Callot 18 March 2003Online Data Format and Condition Database3  This will be the input of the L1CommonBoard Replaces the CROP, common board -> less maintenance problems  What is the format of the output to the DAQ ? We don’t send to L1, so nothing to specify there. We want a compact format, but with calibrated data. Final cell ID should be generated SPDPRSADC contentSPDPRSADC contentParity First cell Second cell Parity Trigger (8bits)ADC value (12 bits)

4. Olivier Callot 18 March 2003Online Data Format and Condition Database4 ECAL and HCAL format  Data is clearly defined 32 bits words Cluster of consecutive cells Specify the ID of only the first cell. 16 bits is enough. Data on 32 bits Floating seems the best (most efficient) Can have integer energy in keV (maximum = 2000 GeV on 32 bits) ID of the first cellCluster length Energy in MeV, float, first cell Energy in MeV, float, second cell Energy in MeV, float, third cell Energy in MeV, float, last cell ID of the first cellCluster length Energy in MeV, float, first cell Energy in MeV, float, next cell First cluster Second cluster

5. Olivier Callot 18 March 2003Online Data Format and Condition Database5  Trigger data is less clear We want to keep unchanged the 8 bits We want to zero-suppress, and minimise the total size Put two consecutive cells and a CellID in a 32 bits word ID of the first cellData first cellData next cell ID of the first cellData first cellData next cell

6. Olivier Callot 18 March 2003Online Data Format and Condition Database6 PreShower and SPD  One solution is to pass the 10 bits unchanged Just put the cell ID in the upper 16 bits But not too easy to use…  Preferred proposal Same format as ECAL-HCAL for the data ADC (special non-linear coding on 8 bits) back to 10, then to keV or float. Trigger data as bit patterns, both Prs and SPD together Send only non empty patterns Should make the data compact enough. ID of the first cell8 SPD bits8 PreShower bits ID of the first cell8 SPD bits8 PreShower bits

7. Olivier Callot 18 March 2003Online Data Format and Condition Database7  Data will be produced by “FE” modules This is the DAQ view, this means by L1 common board module 2 modules for ECAL outer and middle part, Prs outer part. on each side. One module for ECAL inner, hcal inner and outer, Prs middle and outer Total 22 modules  Simulation of the format seems easy But has to be done Some attempt was made, and reported in June 2001 But the code is no longer in Calo/CaloDigit I can probably implement that quite soon Main question is how to define the L1 Common Board boundaries.  Yet another function of the Detector Element ?

8. Olivier Callot 18 March 2003Online Data Format and Condition Database8 Condition Database  Provide data that can change with time Typically alignment, calibration,…  How can we use it in the Calorimeter software ? Replace some constants from XmlDDDB Calibration : GeV per ADC count Calorimeter positions Replace some jobOptions Noise and gain error in the digitisation  What are our special requests None as far as I know Just some values for specified parameters, accessible from the Detector Element or from an Algorithm

9. Olivier Callot 18 March 2003Online Data Format and Condition Database9  Discussion of initial implementation tomorrow First session of the “Software Week” is on alignment and calibration, as this is important for Velo, RICH and tracking If we have special constraints / idea, we could contribute to the discussion I guess we just have this simple requirement Parameters with name and value Alignment to supersede the XmlDDB values  Translation and rotation matrices But I may have forgotten something important ! Speak now…