HMPID offline status report D. Di Bari, L. Molnar, G. Volpe ALICE Offline Week, CERN, 22 June 2009

ONLINE CALIBRATION HMPID calibration and condition parameters Chamber gain (HV, P) Freon (C 6 F 14 ) refractive index CsI quantum efficiency

ONLINE CALIBRATION Q thre = f(V ch,P ch ) HMPID module x y HV sector 2 HV sector 4 HV sector 0 HV sector 3 HV sector 1 HV sector 5 From DCS by the SHUTTLE HV values (six per chamber) end pressure values are retrieved; In the preprocessor Qthre(time) (42 TF1 objects) are created and stored in the OCDB (Calib/Qthre).

ONLINE CALIBRATION HMPID module Tin Tout Tin Tout Radiator vessel 1 Radiator vessel 2 Radiator vessel 3 N freon = f(T,E photon ) From DCS by the SHUTTLE Tin and Tout values are retrieved; In the preprocessor Tin(time) and Tout(time) (42 TF1 objects) are created and stored in the OCDB (Calib/Nmean). x y

Mean photon energy It depends on materials transparency. Quartz transparency is hardcoded and in the preprocessor radiator (C6F14) transparency calculation is implemented; It starts from phototube current values taken from DCS by the SHUTTLE; Photons E mean (1 TF1 object) is calculated and stored in the OCDB (Calib/Nmean); Assuming the temperature uniform long x direction and a linear gradient long y direction, radiator temperature for a given impact track point is calculated (AliHMPIDParam, AliHMPIDTracker). CsI quantum efficiency maps hardcoded (no stored in OCDB). ONLINE CALIBRATION

No updates foreseen for the online calibration; Everything it is already integrate properly in the SHUTTLE framework; From GRP we need of magnetic field in PHYSICS type run; On HMPID side no updates are necessary in the SHUTTLE code running at P2.

ALIGNMENT/CALIBRATION offline procedures No offline calibration procedures are foreseen for HMPID; Calibration is done online (see above); HMPID need alignment procedures; Alignment procedures definition is in progress!! Some problems in the tracking affect the finalization of this task! Let’s remember the status at the March offline week. Mip-track distance Old AliRoot version 3 GeV/c proton, 0.2 Tesla. Only HMPID

Wrong track extrapolation to the HMPID chambers; bug found in AliHMPIDTracker class; magnetic field not used correctly; the problem has been solved. ALIGNMENT/CALIBRATION offline procedures

Mip-track distance Old AliRoot version 2.5 – 3.5 GeV/c proton, 0.2 Tesla.

Xmip – Xtrack Old AliRoot version 2.5 – 3.5 GeV/c protons 0.2 Tesla.

Ymip – Ytrack Old AliRoot version 2.5 – 3.5 GeV/c protons 0.2 Tesla.

ALIGNMENT/CALIBRATION offline procedures Track-mip matching using private propagation method it is ok! Anyway after updating the track with HMPID cluster, last point of the track isn’t in HMPD volume, but in TPC one!! Residuals obtained from AliTracker::FillResiduals(…) method were completely wrong (out of TH1 scale histograms in Global.QA.root); same problem using track extrapolation method inherited from AliExternalTrackParam class! After discussions with Cvetan and Peter (thanks for availability!) has been discovered that in AliESDtrack class there wasn’t the AliExternalTrackParam object for HMPID.

…………………………………………………………………………………………… AliExternalTrackParam *fCp; // Track parameters constrained to the primary vertex AliExternalTrackParam *fIp; // Track parameters estimated at the inner wall of TPC AliExternalTrackParam *fTPCInner; // Track parameters estimated at the inner wall of TPC using the TPC stand-alone AliExternalTrackParam *fOp; // Track parameters estimated at the point of maximal radial coordinate reached during the tracking AliExternalTrackParam *fHMPIDp; // Track parameters estimated at the HMPID ALIGNMENT/CALIBRATION offline procedures In my private aliroot version I update AliESDtrack class adding AliExternaTrackParam object for HMPID, fHMPIDp. ….…..and the relative getter and setter methods: SetOuterHmpParam(..), GetOuterHmpExternalparameters(..), GetOuterHmpExternalCovariance(…), GetOuterHmpXYZ(…), GetOuterHmpPxPyPz(…)

ALIGNMENT/CALIBRATION offline procedures After this modification the last point of the track is in HMPID volume. Track residuals from FillResiduals(..) method are much better, but not yet right!! guns in HMPID chambers 5 GeV/c protons

ALIGNMENT/CALIBRATION offline procedures Residuals are shifted of some millimeters with respect to zero!! the residuals in the third component, not shown in the Global.QA.root histograms, are much larger (about 10 cm); alignment of course doesn’t work in this case! further investigations are in progress!! The procedure adopted to align is within the AliAlignmentTracks environment; we need to store the AliTrackPoints (HMPID cluster + covariance matrix) in the AliESDfriends; memory consumption of alignment procedures is under control.

ALIGNMENT/CALIBRATION offline procedures How many events are needed to align HMPID?! The alignment is done at chamber level; We need of ~ tracks per chamber. No magnetic field event ~ 5 tracks in HMPID per event ~ 5000 events 0.5 Tesla ~ 1 tracks in HMPID in 50 events ~ events

HLT matters We are planning to use HLT, but not for the moment, for the following purpose: Study the possibility to use the SPD FAST-OR trigger; Hidden-Track-Algorithm studies. Performance issues HMPID does not affect the overall CPU and memory consumption both in the simulation and in the reconstruction. Special plans for first data No special plans are foreseen.

We foreseen to add 5 new words to simulated raw data; currently we have only 1 input parameter for the DA (pedestal runs): the sigma cut, that is valid for all chambers; input file (HmpDaqDaConfig.txt) is taken from DAQ DA Database (can be modified by expert via Detector Control Agent); the possibility to mask the dead channels by DA has been considered. DA and RAW DATA

Mask out the dead channels dilogics (we know) Create one file: HmpDaqDaMaskDead.txt in DAQ DA Database; structure based on hardware coordinates: DDL Row Dil Pad isMask (kFALSE) (kTRUE) If file doesn't exist, NO masking at all OR we can mask the dead dilogics anyway (hardcoding in AliHMPIDCalib). DA and RAW DATA

Current “normal” decoding: loosing too much acceptance! Current “turbo” decoding: takes everything no error checks! New decoding for pedestal (at the moment): Markers in place and number; Checksums (payload, segment, row, dilogic) In AliHMPIDRawStream new decoding method LinearPlusCheck will be added; pass error summary to DA (AliHMPIDCalib): could prevent writing pedestal in case of serious problems: different checksums, not existing segments,.... DA and RAW DATA

Add 2D histos to DA (AliHMPIDCalib): HDAMeanPedestal [pad x, pad y, mean pedestal], segmentation: 1 per Chamber HDASigmaPedestal [pad x, pad y, sigma pedestal], segmentation: 1 per Chamber Histos will be decleared in AliHMPIDCalib, stored (probably) in: HmpDAPedestalOutput.root in DAQ DA Db. DA- AMORE integration

SPD FAST-OR trigger for HMPID Because of the small geometrical acceptance of HMPID, it is very important to have a good trigger to enrich the sample of good events for physics; During the last cosmics data taking TOF trigger has been used to select tracks in HMPID acceptance; The possibility to use the SPD FAST-OR signal to provide a trigger for the collision events, has been taken into account by the HMPID group; a Ph.D student (F. Barile) in Bari is dedicated to this subject; let me show some preliminary results!

Silicon Pixel Detector schematic view: SPD FAST-OR trigger for HMPID ALICE Silicon Pixels Detector consists of 1200 chip; If a given chip map is activated by the interaction with charged particle, SPD can provide a FAST-OR signal; it is very important to study the correlation between chips in SPD and the HMPID acceptance; particles in the HMPID acceptance has been simulated in AliRoot.

SPD FAST-OR trigger for HMPID HMPID acceptance

Layer 0 Layer 1 SPD FAST-OR trigger for HMPID B = 0.5 Tesla, 2.5 – 3 GeV/c protons in HMPID acceptance

SPD FAST-OR trigger for HMPID B = 0.5 Tesla, 2.5 – 3 GeV/c protons in HMPID acceptance

(Value %)