1. AliRoot survey: Calibration P.Hristov 11/06/2013

2. Do you participate in calibration activities??(30.5% Yes, 69.5% No) 2

3. Usage of calibration framework (Yes: 92%) 3

4. Evaluation of testing procedures (1- very bad, 5 – very good) 4  DA testing procedure: 3.5  Shuttle testing procedure: 3.8

5. Which are your main sources for DA calibration? 5

6. Inputs for manual calibration 6

7. Reasons for manual calibration and possibility to make it automatic 7  We (T0) have DA for time-amplitude calibration but it requires quick amplitude changes and destroy laser attenuator.  The reason was an issue on the DA side. The fix is to move as much as possible to the preprocessor.  Alignment requires several runs.  Manual intervention was needed in order to cope with a problem that was not expected and obsereved only during the high rate p-A data taking. An "unforeseen" calibration object needed to be added to the framework.  Need for high statistics. A framework allowing merging over several runs could be helpful

8. Reasons for manual calibration and possibility to make it automatic 8  SDD calib. requires creation of correction maps which require lot of statistics (at least few merged fills data) from heterogeneous data. Currently it is done via semiautomatic procedure, normally the user needs just to validate the automatically generated scripts. Making it fully automatic will not fit to current run-by-run calib. scheme and will be error prone. In Run3 there will be no SDD anyway.  Alignment: rare process, no need to do this automatically. And impossible to do this: need large stat. complicated relationship between different detectors. Dedicated framework shall be developed for future

9. Reasons for manual calibration and possibility to make it automatic 9  The offline calibration in my case (HMPID) consists in the alignment, at the moment in the framework alignment is not an automatic procedure.  1. Combination of the B0, B+, B- data. (other algorithm to develop) 2. dEdx - many iteration - to be replaced storing un-binned data for the calibration (trees)  1) Calibration need a statistics of the whole period of several periods. 2) Calibration is sometimes subjective, its quality if multi- parameter task which needs a human intervention. For example, bad channel map is always a compromise between channel quality and available statistics.  Need large amount of data to calibrate, bigger than a typical large period.

10. How often do you update the parameters in your manual calibration? 10

11. What is the main criterion for new calibrations? 11  Change of data taking conditions: 80%  Statistics: 28%  Other: 12%  intervention on detector which moves it  most parameters have to be checked at each fill  change of running period

12. What are the advantages/disadvantages of the OCDB framework? Advantages Disadvantages 12  consistent and kept under control set of parameters  keep the calibration status under control and assuring reproducibility of the results  one "single" point of access for the calibrations for online,HLT,offline  suits our needs  single instance for all processes  run dependence by design  bad accessibility via Grid, too slow, big objects  OCDB is 1 dimensional and not easily related to an aliroot version  possibility of errors due to mismatch between aliroot code and OCDB object version  time spent to deal with it in case of issues  only experts know what it is and the effort needed to develop it  the AliRoot objects need strict compatibility policy  no mechanism to follow AliRoot versions  snapshots contradict the idea of singe instance

13. What is your calibration algorithm mainly doing? 13

14. How complicated is the fitting procedure (1 - very simple, 5 - very complex)? 14 Mean: 3.3

15. How do you benchmark your calibration procedures? 15 Other: stability of result after several iterations

16. What is the bottleneck in your calibration? 16 Other: requires manual (expert) handling

17. Proposed improvements 17  the 2D relation of aliroot version and run number  easier way to have a local copy for a couple of runs (to e.g. debug the reconstruction) for the objects required by the reco. would be a plus.  It would be very beneficial to have calibration events separated out from physics events - i.e. separate data file(s)/stream(s): preferably one for each detector if that would be OK (if that would mean too many files having one calibration stream for all calibration events would also be a big improvement). I.e. TOF calibration events in one stream, TPC calibration events in a second stream, EMCal in a third etc., and not mixed in with physics events. This would be an enormous help for us in cases where one wants to have a second look at calibration events/info, and would not need to make a full pass through all data to find them.  Configuration of the OCDB hardwired, in case we want to change OCDB we have to change sim.C or rec.C which can leads to confusion. I prefer ConfigOCDB.C macro which will be consistent and easy to test  access via grid  easy snapshots, versioning, offline access

18. Which calibration does already fit or can fit the online constraints? 18  TPC will move online during LS1  Everything at T0 CPasses can be done online inside HLT framework.  Pedestals (and gains) are already done online (in DAs)  For ITS all but mean vertexer with tracks and SDD drift speed calibration  None, due to statistics requirements. On top, reconstructed ESDs are needed.  almost all algorithms should run online resp. should collect information online  Low-gain/high-gain ratio is already working in online DA.  in principle everything can be done online, work is ongoing, need some additional features from upstream (like ITS standalone reco in HLT)  Temperature dependent gain corrections per run

19. Conclusions 19  Several reasons lead to manual calibration. Among them the most important is the required statistics  Some issues of the OCDB framework were identified, for example the missing information about the AliRoot version in the objects  Possible improvements in the processing, i.e. “skimming” of calibration events per detector  The calibration group should discuss the details of the proposals