Steering the Reconstruction Parameters C Cheshkov ALICE Offline

Steering the Reconstruction Parameters C. Cheshkov ALICE Offline Week 9 July 2008

Motivation Need in much lighter rec. C for central quasi-online Ali. En-based raw-data reconstruction: Building of proper rec. C takes quite some time and requires discussions with the detector experts Keeping track of parameters used in the reconstruction is not straightforward and certainly will become difficult with the start of LHC Raw-data files will contain mixture of different event types (for example cosmics + collisions): Reconstruction parameters depend strongly on the event type and should be steered on event-by-event basis Putting some order in the reconstruction steering will make the code more reliable

Basic Requirements Possibility to steer the reconstruction according to the Global Running Conditions (GRP) of the experiment and the machine Possibility to select different reconstruction parameters on event-by-event basis taking into account the trigger information (CTP + HLT) and the event type All the reconstruction parameters are fully contained in OCDB for all the runs that are being centrally reconstructed

Implementation: GRP + event properties Ali. Event. Info class: TObj. String f. LHCState; // state of the machine as provided by DCS and DAQ log-book (per run) TObj. String f. Beam. Type; // beam type for Alice TObj. String f. Run. Type; // run type accoring to ECS (per run) TObj. String f. Active. Detectors; // list of active detectors (per run) UInt_t f. Event. Type; // event type as defined by DAQ (start_of_*, calibration, physics etc) (per event) TObj. String f. Trigger. Classes; // list of fired trigger classes (per event) ULong 64_t f. Trigger. Mask; // trigger mask as received from DAQ or CTP raw-data payload (per event) TObj. String f. Trigger. Cluster; // list of detectors that have been read out (per event) TObj. String f. HLTDecision; // string describing the HLT decision (per event)

Implementation: Detector reco parameters per event type Ali. Detector. Reco. Param base class (Tnamed) Detectors are free in their implementations Simpler structure and usage of basic types Should be readable by everybody, not just offline experts Note: Ali. Detector. Reco. Param name will be changed to Ali. Event. Reco. Param or Ali. Det. Event. Reco. Param which is more appropriate

Implementation: Detector reco parameters container Ali. Reco. Param base class Simple container of individual Ali. Detector. Reco. Param objects Detectors derive from it and implement the method to choose Ali. Detector. Reco. Param according to the information inside Ali. Event. Info Detectors which have only one Ali. Detector. Reco. Param for different event type use directly the base class We are planning to put some 'helper' methods in the base class in order to facilitate the decision to be taken by the detectors Better have bigger array of reco-params and longer run range Note: Ali. Reco. Param name will be changed to Ali. Detector. Reco. Params or Ali. Det. Reco. Param. Array which is more appropriate

Implementation: reconstructors and trackers Ali. Reconstructor and Ali. Tracker base classes will contain a pointer to the corresponding Ali. Detector. Reco. Param object Simple setter and getter will be provided instead of the present static ones Please do not cache by any means the infromation in the reco-param object

Implementation: Ali. Reconstruction 'Run' part of Ali. Event. Info GRP entry from OCDB Creation of Ali. Reco. Param's Ali. Reco. Param or Ali. Detector. Reco. Param object from OCDB XXX/Calib/Reco. Param Initialization Inside event loop 'Event' part of Ali. Event. Info Ali. Reco. Param's: Selection Ali. Detector. Reco. Param Detector's reconstructor and tracker CTP config from OCDB, CTP trigger and clusters masks from event header, HLT decision

Trigger classes naming convention Prepared by F. Antinori http: //aliceinfo. cern. ch/Offline/Activities/Trigger. Patt ern. html Supposed to help the reconstruction in getting the event type based on the trigger information Trigger class name (ID) contains all the essential information about the trigger inputs logic, past-future protection, bunch-crossing mask, detector clusters etc. The handling should be much easier – instead of digging into the trigger configuration one can just analyze the class name

Issues Usage of some reconstruction parameters at the initialization step (outside event loop) Clarified with the concerned detectors Solutions are being identified and will be implemented For example TRD would need a debug level in order to instantiate a debug stream and an option whenever to unload/load rec-points during tracking In ITS we would need at least two vertexers instead of only one Multiple usage of the static Ali. Reconstructor: : Set/Get. Reco. Param() methods: Quite dangerous/bad-style/non-modular Setters were removed Quite a lot of technical work to remove properly the getters

Status and Plans Ali. Event. Info, Ali. Reco. Param and Ali. Detector. Reco. Param are already in the trunk More information of some of the GRP entries and possibly some of the helper Ali. Reco. Param methods by the end of the week Prototype of the changes to Ali. Reconstruction and reconstructors has been written and sent to ITS, TPC, TRD, PHOS and MUON experts for opinion and possible fixes We are planning to commit a working version of the whole scheme by the end of the week (just before the branching of v 4 -14 -Release) Depending on the progress with the removal of the static methods, the corresponding code will be committed to the trunk and the release branch

Prepare an example macro for producing and storing in OCDB Ali. XXXReco. Param objects, detectors will be asked to follow Quite some work (mostly technical) in front of us, but I am sure it will pay off as the code will become much more 'steerable' and reliable Questions. . .