This page is a branch of the main AHCALTestBeamCERN2015 page and describes the basics for offline data analysis of the data taken during the AHCAL testbeam campaigns at SPS-CERN during summer 2015.


Offline Data Analysis: using EUDAQ files

EUDAQ: output files

The EUDAQ frame saves two different kind of files:

The slcio contain two different collections, one called EUDAQDataScCal, which contains the channel by channel information:

        Event  : 1 - run:  24528 - timestamp -1 - weight 1
 date:      01.01.1970  00:00:00.000000000
 detector : unknown
 event parameters:
 collection name : EUDAQDataScCAL
--------------- print out of LCGenericObject collection ---------------
  flag:  0x0
 parameter Timestamp_i [int]: 1437317239,
 parameter Timestamp_usec [int]: 442595,
 parameter DataDescription [string]: i:CycleNr;i:BunchXID;i:ChipID;i:EvtNr;i:Channel;i:TDC;i:ADC;i:HitBit;i:GainBit,
 parameter Timestamp [string]: Sun, 19 Jul 2015 16:47:19 +0200,
 parameter TypeName [string]: CaliceArray,
 [   id   ] i:CycleNr;i:BunchXID;i:ChipID;i:EvtNr;i:Channel;i:TDC;i:ADC;i:HitBit;i:GainBit - isFixedSize: false
 [00000004] i:0; i:0; i:137; i:0; i:35; i:1066; i:0; i:1; i:1;  --------------------------------------------------------
 [00000005] i:0; i:0; i:137; i:0; i:34; i:1165; i:0; i:1; i:1;  --------------------------------------------------------
 [00000006] i:0; i:0; i:137; i:0; i:33; i:1210; i:0; i:1; i:1;  --------------------------------------------------------
 [00000007] i:0; i:0; i:137; i:0; i:32; i:1156; i:0; i:1; i:1;  --------------------------------------------------------



And other called TempSensor which contain the temperature sensors information.

 collection name : TempSensor
--------------- print out of LCGenericObject collection ---------------
  flag:  0x0
 parameter Timestamp_i [int]: 1437317247,
 parameter Timestamp_usec [int]: 195330,
 parameter DataDescription [string]: i:LDA;i:port;i:T1;i:T2;i:T3;i:T4;i:T5;i:T6;i:TDIF;i:TPWR,
 parameter Timestamp [string]: Sun, 19 Jul 2015 16:47:27 +0200,
 parameter TypeName [string]: CaliceArray,
 [   id   ] i:CycleNr;i:BunchXID;i:ChipID;i:EvtNr;i:Channel;i:TDC;i:ADC;i:HitBit;i:GainBit - isFixedSize: false
 [00013690] i:0; i:0; i:301; i:296; i:298; i:294; i:299; i:316; i:31; i:43;  --------------------------------------------------------
 [00013691] i:0; i:1; i:344; i:337; i:339; i:335; i:342; i:359; i:31; i:42;  --------------------------------------------------------
 [00013692] i:0; i:2; i:329; i:312; i:320; i:315; i:320; i:313; i:30; i:45;  --------------------------------------------------------
 [00013693] i:0; i:3; i:328; i:308; i:315; i:311; i:316; i:309; i:30; i:42;  --------------------------------------------------------
 [00013694] i:0; i:4; i:369; i:352; i:367; i:353; i:356; i:362; i:29; i:42;  --------------------------------------------------------
 [00013695] i:0; i:5; i:328; i:310; i:319; i:315; i:319; i:312; i:29; i:41;  --------------------------------------------------------
 [00013696] i:0; i:6; i:318; i:300; i:305; i:302; i:305; i:300; i:29; i:42;  --------------------------------------------------------
 [00013697] i:0; i:7; i:337; i:313; i:321; i:319; i:322; i:315; i:31; i:41;  --------------------------------------------------------
 [00013698] i:0; i:8; i:317; i:301; i:309; i:307; i:310; i:304; i:30; i:44;  --------------------------------------------------------
 [00013699] i:0; i:9; i:338; i:320; i:326; i:324; i:326; i:322; i:31; i:47;  --------------------------------------------------------
 [00013700] i:0; i:10; i:363; i:350; i:0; i:332; i:0; i:335; i:33; i:48;  --------------------------------------------------------
 [00013701] i:0; i:11; i:322; i:313; i:308; i:302; i:309; i:301; i:33; i:54;  --------------------------------------------------------
 [00013702] i:0; i:12; i:336; i:329; i:328; i:317; i:330; i:314; i:34; i:57;  --------------------------------------------------------
 [00013703] i:0; i:13; i:304; i:291; i:291; i:281; i:294; i:277; i:33; i:55;  --------------------------------------------------------

/!\ In this collection the

 [   id   ] i:CycleNr;i:BunchXID;i:ChipID;i:EvtNr;i:Channel;i:TDC;i:ADC;i:HitBit;i:GainBit - isFixedSize: false

is not correct, to be fixed.

Every different raw is associated to a different LDA port which order do not match with its physical position with respect to the beam !! The matching table is in the setup section.

Why the "raw" surname of the slcio file?

This is because the slcio file that is created online while the data taking, does not have any eventbuilding. Therefore, there is no sorting by BunchXID or ChipID, just one entry for each readout cycle defined by our electronics.

The basic event building is done offline.

General instruction to install and run testbeam analysis software can be found in the Calice_soft wiki page and in the Analysis section of this wiki page.

The Calice_soft_tb2014 contains five different set of processors:

This software use, as first input file, the labview txt files. With the presence of the EUDAQ framework slaving the labview, we also have the mentioned above "raw slcio" files, which can be used for analysis. For that we need a processor that converts the raw lcio file into a lcio file which can be used by our software. More precisely, what we need is to create an lcio file with well defined events instead of collections defined by the readout cycle of our DAQ which have no physical meaning. This is done and explained in the next section. This files are then ready to used in our analysis.

Moreover, the raw slcio files also contain the temperature measures of the detector during the run duration. This information can be extracted directly from the raw slcio data (or from the data after the event building process) and saved in a root tree. See Temperature Reading section.

EUDAQ: Event Building

The first thing to do if we want to use the eudaq slcio files for offline analysis is to perform the basic event building. This basic event building consist in a sorting of the ADC and TDC information for every channel according to the BXID (instead of raw readout cycle sorting) and the ChipID (to distinguish between ECAL or HCAL). This event building is schematically shown in the following picture (where the temperature information is already included):


The proccessor that performs this sorting, EUDAQEventBuilder, is already implemented in the svn repository. To install it and run it - sl6 -, you should do the following:

First, create your installation folder, copy the cmake files in your path and modify them accordingly (look for the lines where the user "airqui" is used, and change this to show your own path)

cd $yourpath
mkdir myInstall
cp -r /afs/ $yourpath

You will also need the


file, modified accordingly to point to your installation folder and not to the calice pro_test installation. The file is located in the calice pro_test folder:

cp /afs/ $yourpath/.

These are the important lines where you must substitute




     CACHE PATH "Install prefix" FORCE)

# set CMAKE_MODULE_PATH for backwards compatibility directly to ILCUTIL_DIR/cmakemodules
SET( CMAKE_MODULE_PATH "${ILC_HOME}/ilcutil/v01-02/cmakemodules" CACHE PATH "Path to CMakeModules" FORCE)

############## CALICE ############################
     CACHE PATH "Path to CMake Modules" FORCE )
    CACHE PATH "Path to pro_test cmake files")

Once the environment variables are properly set. you can proceed with the svn checout and the compilation of the different packages. For that, you can write and execute a script with the following instructions:

svn co
svn co
svn co
svn co
svn co

mkdir build_calice_userlib
cd build_calice_userlib/
cmake -C ../user-pro-test_x86_64_gcc44_sl6.cmake ../calice_userlib/
make install
cd ..
mkdir build_labview-converter
cd build_labview-converter
cmake -C ../user-pro-test_x86_64_gcc44_sl6.cmake ../labview-converter/
make install
mkdir build_calice_analysis
cd build_calice_analysis/
cmake -C ../user-pro-test_x86_64_gcc44_sl6.cmake ../calice_analysis/
make install
cd ..
mkdir build_RootTreeWriter
cd build_RootTreeWriter
cmake -C ../user-pro-test_x86_64_gcc44_sl6.cmake ../RootTreeWriter/
make install
cd ..
mkdir build_calice_reco
cd build_calice_reco
cmake -C ../user-pro-test_x86_64_gcc44_sl6.cmake ../calice_reco/
make install
cd ..

To run it, you need to define your marlin file (EUDAQMarlin) pointing to your compiled libraries and a steering file setting the input and output parameters to run the EUDAQEventBuilder processor. You can find an example of steering file in this file: EUDAQEventBuilder.xml. To execute it:

./EUDAQMarlin EUDAQEventBuilder.xml

The main parts of this steering file are:

1) Input lcio file

 <parameter name="LCIOInputFiles">
  <!-- limit the number of processed records (run+evt): -->
  <parameter name="MaxRecordNumber" value="0" />
  <parameter name="SkipNEvents" value="0" />
  <parameter name="SupressCheck" value="false" />
  <parameter name="Verbosity" options="DEBUG0-4,MESSAGE0-4,WARNING0-4,ERROR0-4,SILENT"> SILENT </parameter>

2) Processor settings, where we define the name of the input and output collections.

 <processor name="EUDAQEventBuilder" type="EUDAQEventBuilder">
    <parameter name="DetectorType" type="string">ScCAL </parameter>
  <!--Name of the input collection of EUDAQ lcio raw data-->
  <parameter name="InputCollectionName" type="string"> EUDAQDataScCAL </parameter>
  <!--Name of the input collection of EUDAQ temperature sensor data-->
  <parameter name="InputCollectionNameTemp" type="string">TempSensor </parameter>
  <!--Name of the output collection of EUDAQ lcio ECAL  data-->
  <parameter name="OutputCollectionNameECAL" type="string"> EUDAQDataECAL </parameter>
<!--Name of the output collection of EUDAQ lcio HCAL  data-->
  <parameter name="OutputCollectionNameHCAL" type="string"> EUDAQDataHCAL </parameter>
  <!--verbosity level of this processor ("DEBUG0-4,MESSAGE0-4,WARNING0-4,ERROR0-4,SILENT")-->
  <!--parameter name="Verbosity" type="string">DEBUG </parameter-->

3) The slcio output file

<processor name="MyLCIOOutputProcessor" type="LCIOOutputProcessor">
 <!--Writes the current event to the specified LCIO outputfile. Needs to be the last ActiveProcessor.-->
  <!--Type name of the detector. Currently valid identifiers are: AHC2, AHC2M AEC-->
  <!--parameter name="DetectorType" type="string">ScCAL </parameter>
  <!--drops the named collections from the event-->
  <!--parameter name="DropCollectionNames" type="StringVec"> EUDAQDataScCAL TempSensor </parameter>
  <!--parameter name="FullSubsetCollections" type="StringVec"> EUDAQDataHCAL EUDAQDataECAL </parameter>
  <!-- name of output file -->
   <parameter name="LCIOOutputFile" type="string"> /nfs/dust/ilc/user/airqui/CERN_SPS_July_2015/EventBuilt/Pion/90GeV/FILENAME_EventBuilt.slcio </parameter>
  <!--write mode for output file:  WRITE_APPEND or WRITE_NEW-->
  <parameter name="LCIOWriteMode" type="string"> WRITE_NEW </parameter>

EUDAQ: Temperature Reading

Starting from the the setup described above, is easy to create a new processor to extract the temperature information from the slcio data. This is done in the TempRootTreeGenerator processor which basically reads the temperature from the slcio file and saves it in a root tree. You can find here the needed source and header files.

First we need to copy the software to the proper directory in the RootTreeWriter folder: The file to the


and the correspondent header file to the


folders before starting the re-compilation procedure:

cd $yourpath/build_RootTreeWriter
make clean
cmake -C ../user-pro-test_x86_64_gcc44_sl6.cmake ../RootTreeWriter/
make install

We can use our previous marlin file and a new the steering file similar to the described in the previous section. Here you can find the two main ingredients of the steering file: the input slcio file and the processor that makes the conversion (slcio to root). The first is a global variable in our steering file.

 <parameter name="LCIOInputFiles">
  <!-- limit the number of processed records (run+evt): -->
  <parameter name="MaxRecordNumber" value="0" />
  <parameter name="SkipNEvents" value="0" />
  <parameter name="SupressCheck" value="false" />
  <parameter name="Verbosity" options="DEBUG0-4,MESSAGE0-4,WARNING0-4,ERROR0-4,SILENT"> SILENT </parameter>

The main processor is:

<!-- Write root file containing raw data -->
  <processor name="MyTempRootTreeGenerator" type="TempRootTreeGenerator">
    <!--Processor to generate root tree for T0 currently-->
    <!--Name of the input collection of Labview raw data-->
    <parameter name="InputCollectionName" type="string"> TempSensor </parameter>
    <!--Name of the Branch-->
    <parameter name="BranchPrefix" type="string">  </parameter>
    <!--Name of the output root file-->
    <parameter name="OutputRootFileName" type="string"> /nfs/dust/ilc/user/airqui/TestBeamAugust2015/TemperatureReading/rootfiles/Pions/120GeV/Temp_Run_30001__12p08p2015__19p41p53.root
    <!--verbosity level of this processor
    <parameter name="Verbosity" type="string"> SILENT </parameter>

Where the only parameters are the "InputCollectionName" and the "OutputRootFileName". By default, the "OutputCollectionName" is "TemperatureSensor".

Finally we are ready to run it:

./EUDAQMarlin EUDAQTemperature.xml

The better way to study the output root file is out of the scope of this wiki, so we don't enter in this point. Of course, if you write an intelligent and useful root script that the others could use to read these files, you are more than invited to share with everyone in this wiki. Here is an example of the average temperature (averaging for the 6 sensors) of each layer during the first days of data taking in August.

Detector Temperature August

Offline Data Analysis: Mapping

Here is a mapping file for the July Testbeam data (Here is the one for August). This file contains a mapping of the detector with "#Layer Chip Chn I J K". Layer represent the Layer number from 1 to 14. I, J, K represent the detector coordinates in the detector frame (i.e the bottom right corner represent the origin of the axes). Here K represent the layer number also, a modification would be needed to compare data and MC (in MC, the K represent the layer number in the complete detector including empty space between absorbers).

Offline Data Analysis: Database

For the reconstruction, several constants/parameters are needed (MIP Value, Gain values, Number of effective pixels, Dead channel map, Gain/MIP Temperature dependence..). All theses constants are put into a database that during the reconstruction a processor get theses variables automatically for each channels.

If any changes in the database is needed (calibration constants, framework...), please contact DESY people

For July and August, the database folder is the following : /cd_calice_cernSPS2015/TestbeamJuly2015/ & /cd_calice_cernSPS2015/TestbeamAugust2015/. In the steering file for the reconstruction you need to put theses paths :

<!-- DB parameters + Mapper -->

  <processor name="GeoConditions" type="ConditionsProcessor">
    <parameter name="DBInit" type="string" value=""/>
    <parameter name="DBCondHandler" type="StringVec">
      Ahc2ModuleDescription        /cd_calice_cernSPS2015/TestbeamJuly2015/ModuleDescription               HEAD
      Ahc2ModuleConnection         /cd_calice_cernSPS2015/TestbeamJuly2015/ModuleConnection                HEAD
      Ahc2ModuleLocationReference  /cd_calice_cernSPS2015/TestbeamJuly2015/ModuleLocationReference         HEAD
      Ahc2DetectorTransformation   /cd_calice_cernSPS2015/TestbeamJuly2015/DetectorTransformation          HEAD
      Ahc2HardwareConnection       /cd_calice_cernSPS2015/TestbeamJuly2015/Ahc2HardwareConnection          HEAD
      E4DPedestal                  /cd_calice_cernSPS2015/TestbeamJuly2015/Pedestal                        HEAD
      E4DGainConstants             /cd_calice_cernSPS2015/TestbeamJuly2015/gain_constants                  HEAD
      E4DGainSlopes                /cd_calice_cernSPS2015/TestbeamJuly2015/gain_slopes                     HEAD
      E4DMipConstants              /cd_calice_cernSPS2015/TestbeamJuly2015/mip_constants                   HEAD
      E4DMipSlopes                 /cd_calice_cernSPS2015/TestbeamJuly2015/mip_slopes                      HEAD
      E4DDeadCellMap               /cd_calice_cernSPS2015/TestbeamJuly2015/DeadCellMap                     HEAD
      E4DSaturationParameters      /cd_calice_cernSPS2015/TestbeamJuly2015/SaturationParameters            HEAD
      E4DIntercalibration          /cd_calice_cernSPS2015/TestbeamJuly2015/Intercalibration                HEAD
      E4DPhysicsCalibIntercalibration          /cd_calice_cernSPS2015/TestbeamJuly2015/PhysicsCalibIntercalibration                HEAD

The following will explain each of them. You can find here the different tags related to both periods.


This is the collection containing the description of the Modules. It indicates the type : EBU0/1/2 or Single HBU or 2*2 HBU, the geometry parameters like size and sensitive material grid size. This Description is depending on the actual orientation of the layer in the real world. Thus different descriptions needs to be done depending on the orientation : Top-Readout/ Left or Right-Readout. The initial file needs to be done manually in this format :

#Module   Chip    Chn    CellID1     I       J       K      CellID0
   3       0       0        3        3       11      1       360640

Module represent the module type (from 1 to 5 - 3 EBU0, 4 EBU1, 5 EBU2, 1 single HBU, 2 2*2 HBU). The CellID1 is a encoding number to get back the hardware description : it is in this format "module:6,chip:4,chan:6,SiPM:16". I, J, K is the detector coordinates (representing a cell (I, J) and the layer (K)). It is encoded in a number the CellID0. This number is the most important as each calibration value is attached to a CellID0. It is encoded as the following : "M:3,S-1:3,I:9,J:9,K-1:6"

(module & 0x3f << 6) + (chip & 0xf << 4) + (chan & 0x3f << 6)
module : mask 0x3f on 6 bits
chip : mask 0xf on 4 bits
chan : mask 0x3f on 6 bits

(I & 0x1ff) << 6) + ((J & 0x1ff) << 15) + ((K-1 & 0x3f) << 24)
I : mask 0x1ff on 6 bits
J : mask 0x1ff on 9 bits
K-1 : mask 0x3f on 9 bits

It is a bit complicated and if you want to have a look : look into calice_userlib (include/Mapping).


This collection connects the Module_Type (0 single HBU, 2 2*2 HBU, 4 EBU0, 6 EBU1, 8 EBU2) contained in the ModuleDescription to a certain layer in the testbeam setup. For example :

      if (ilayer==1)//EBU0
        module_type = 4;
      if (ilayer==2)//EBU1
        module_type = 6;
      if (ilayer==3)//EBU2
        module_type = 8;
      if (ilayer>=4 && ilayer<=11)//Single HBU
        module_type = 0;
      if (ilayer>=12)//2x2 HBUs
        module_type = 2;


This collection assign the z position of a layer. For example :

for (int ilayer = 1; ilayer <= 15; ilayer++)
      /* add staggering*/
      float z = (ilayer-1)*26.5;//should be increased with thickness Layer

      if (ilayer==13)
        z = 13*26.5;
      if (ilayer==14)
        z = 21*26.5;
      if (ilayer==15)
        z = 31*26.5;


This collection indicates the relative position of the detector to the beam by usually an angle. Currently for the EPT Prototype this does not work. Anyway the detector was faced perpendicularly to the beam.


This collection is important. It links hardware information to the ModuleDescription during the reconstruction. The collection is in the form : Chip / ModuleNumber or Layer / ChipID. It is mandatory to run the reconstruction!!


Calibration Values

In the following, I will describe how each calibration values were determined. 'Packages for Pedestal, Noise and MIP Extraction are available in calice_ROOTmacros package in calice soft.'

Upload on the database

/!\ This should only be performed by experts /!\

Upload is fairly simple. You need the package calice_cddata compiled in order to upload calibration values to the database. Each calibration constants have a specific structure to be uploaded depending on the type of constants. There are 5 types :

To upload it should have this format :

<CaliceSoftInstallPath>/bin/write<type> --inFile <InputFile.txt> --dbinit <dbaddress>  --folder <dbfolder> --parameterFile <defaultfile.txt> --from <timestamp_start> --until <timestamp_end> --write

The <defaultfile.txt> should be in the form :

float: defaultValue <default_value>
float: defaultError <default_value_error>
float: defaultReferencePoint <default_ref_value>
float: defaultReferencePointError <default_ref_value_error>
string: CollectionName <collection_name>

For example to upload Pedestal data, you need to write :

<CaliceSoftInstallPath>/bin/writeSimpleValues --inFile <InputPedestalFile.txt> --dbinit <dbaddress>  --folder <dbfolder> --parameterFile <defaultfile.txt> --from 2015-07-01-00-00-00-000000000 --until 2015-07-31-23-59-59-000000000 --write

The input format should be :

Module ChipNumber Channel Pedestal Pedestal_error status (status = 1)

Module ChipNumber Channel Gain/MIP Gain_error/MIP_error Ref_value Ref_value_error

Module ChipNumber Channel slope slope_error

Module ChipNumber Channel status (status = 0)

Module ChipNumber Channel NeffPx fraction epsilon


Pedestal values are obtained from raw data during Muon runs. First, an histogram for each chip / channel / memory cell is filled for hits with HitBit == 0 and rejecting the memory cell 0 and the first 10 cycles. After, for each histogram. The mean and RMS is taken in a range of 3 sigma around the mean value if the histogram contains more than 5000 entries. We obtain then a pedestal value for each chip / channel / memcell. We compute the pedestal for each chip / channel by taking the mean of the value of each memory cell same for the RMS. Then quality cuts on the RMS of the pedestal are done in order to remove dead or noisy channels (Making a map from it also). Each type of SiPM has its own sets of cuts.



The MIP Calibration is obtained from the Muon Runs using a TrackFinder (Ahc2MipTrackFinder). It was done for a Tower of 8 hits or more and a maximum number of hits of 30 per event. The calibration is done once (Chi2 and ML methods) to get a rough estimate of the MIP Position, outliers are then rejected and an iteration is then done again with 0.5 MIP cut. The final values obtained are a mix of February / April (Big Layers outer tiles) and July data. No temperature correction is taken into account between February / April and July. If no value was found for a cell, then the Mean of the Module distribution is taken and the RMS of the distribution as an error.

MIPModule3 MIPJuly

MIP slope

No particular study was done yet on this constants. Just one channel was looked at for the Mainz board in order to see if the slope goes into the right direction. One has to do the study for each channels!. So far default values were put into the database. A slope of -3%/K or -1%/K was taken multiply by the MIP value of the corresponding cell. For reconstructed file, so far no temperature correction is done (One has to integrate Temperature reading into the database).


The Gain calibration was performed on Gain measurements done before the Testbeam period in July (from 04/07 to 08/07). For each channel, an histogram is filled using all the data available. If there are enough entries in the histogram a gaussian fit is performed and the Gain is then extracted from the fit and the error as RMS. If not, then the mean of the histogram is taken (RMS as error). At the end, an outlier rejection is done and if a cell does not have a value, a default value is put using the Mean distribution of the Module and the RMS as error.


Gain slope

No profound study was perform to determine the Gain-Temperature dependence. Just at a first look, the slope are similar to the specification said by the SiPM manufacture. The slopes are -0.5%/K for the new ITEP, -1%/K for the Ketek and SenSL, -1.5%/K for the SMD Mainz and -2.1%/K for the EBUs and the old ITEP multiply by the gain value of the corresponding cell. For reconstructed file, so far no temperature correction is done (One has to integrate Temperature reading into the database).

Saturation Parameters

Normally, each SiPM should be provided with their saturation curve. From this curve, the number of effective pixels (can be equal as the real number of pixels, or more or less) is extracted. This is important for the digitization and mostly the saturation behaviour of the SiPM. For now, a default value as been put into the database based on the number of pixels of the SiPM.


As the SPIROC can operate in 2 different modes (HG and LG), we need to know precisely for each channels the ratio between both to reconstruct correctly the energy measured. The default value should be 10 but based on some studies before we know that it can vary between 8 and 12 in auto-trigger.

Intercalibration Physics/Calib

This constant is specific to the new ITEP boards that operated in a different mode during physics runs. A default value of 1 is provided for all the boards and a default value of 7 is provided for the new ITEP boards. This value should be calibrated for each channels on theses boards. (Can be obtained using Calib/Physics MIP runs).

Offline Data : Software Framework

A doxygen page can be found there for the different software available in calice soft :


The goal is to keep the dataflow of simulated data and real data the same. At the end of the digitisation, the simulated data should look like exactly the same as real data (ADC). Thus the reconstruction is applied in the same way to data and simulation. /!\ Only Pedestal in simulation is not implemented as there is no need to do so.

Dataflow for AHCAL

The digitisation performs :

The reconstruction performs :

To be done : Gain/MIP correction based on temperature data and error propagation.


A list of good runs can be found there.

To avoid problems with the software and also proliferation of data from individual parties, a central place on the grid is dedicated to Reconstructed files. Theses files will be produced will the standard latest calibration constants. Still to be clarified, to assign a responsible person for it. Only good runs will be reconstructed. If you need a particular run to be reconstructed that is not available, contact DESY people.

One can find the files there : /pnfs/


In the Muons folder /pnfs/ Each Runs contains the reconstructed collections LabviewDataXXXX/Ahc2_CalorimeterHits/ScEcal_CalorimeterHits and also the Temperature collection. Slow control is still not implemented as a collection!!!. Zero suppression of 0.5 MIP, Pedestal substracted, MIP conversion, no saturation correction and filter dead channels.

Steering file used : steering_Muon_SPSJuly.xml


In the Pions folder /pnfs/ Each Runs contains the reconstructed collections Ahc2_CalorimeterHits/ScEcal_CalorimeterHits and also the Temperature collection. Slow control is still not implemented as a collection!!!. Zero suppression of 0.5 MIP, Pedestal substracted, MIP conversion, Saturation correction and filter dead channels.

Steering file used : steering_Pion_SPSJuly.xml


In the Electrons folder /pnfs/ Each Runs contains the reconstructed collections Ahc2_CalorimeterHits/ScEcal_CalorimeterHits and also the Temperature collection. Slow control is still not implemented as a collection!!!. Zero suppression of 0.5 MIP, Pedestal substracted, MIP conversion, Saturation correction and filter dead channels.

Steering file used : steering_Electron_SPSJuly.xml


Simulation files will be produced centrally and available on the grid. If you want any simulated data, please contact /!\ ???. More info here. A page is explaining how to compile Mokka/DD4HEP with the current HCAL driver, see here.

AHCALTestBeamCERN2015/OfflineDataAnalysis (last edited 2018-05-14 15:40:07 by VladimirBocharnikov)