Th points to be discussed during this review are listed below. Each detector should attach its presentation at least one day before the respective meeting.
Offline
- Geometry:
- are any changes in the geometry and material descriptions expected/foreseen?
- is the current situation satisfactory?
- full/survey misalignment: is it possible to introduce full or survey misalignment without creating overlaps?
- Material budget:
- is the current step size good for the calculation of material budget and for energy loss correction?
- Simulation:
- Time information in simulation (needed for pileup sim and more realistic detector response - this item is new, we never asked them before!)
- Is step manager correctly storing the time of the hits
- Does the digitization take into account the time of the hits
- Does the digitization simulates correctly the time response of the readout (binning, time windows etc.)
- is the memory and CPU consumption under control at each simulation step: hits, sdigits, digits?
- labels: are the labels from the kinematics tree correctly propagated to hits, sdigits, digits?
- track references: are the track references needed and if yes, are they correctly implemented in the step manager?
- event merging: is the event merging correctly working for the detector?
- embedding: is the track embedding foreseen in your detector? If yes, is it working correctly?
- Time information in simulation (needed for pileup sim and more realistic detector response - this item is new, we never asked them before!)
- Raw data:
- is the raw data format already fixed, or additional changes are needed?
- OCDB parameters : simulation vs reconstruction
- are the gains stored in OCDB correctly used both in the simulation and reconstruction?
- LHC machine parameters to go to GRP
- Reconstruction:
- Are all the necessary reco params in OCDB (including params for cosmic reco)
- Are reco params fully used in the reco
- track reconstruction:
- shift in the reconstructed Pt: is the problem understood ans is the current situation satisfactory?
- doubly found tracks: is the reported increase confirmed and is the origin understood?
- is the propagation status correctly taken into account? If the propagation fails, are the track parameters left unchanged?
- Is the time information taken into account (needed for pileup)
- V0 reconstruction:
- low V0 efficiency if the propagation failed
- like sign V0s requested for background studies https://savannah.cern.ch/bugs/index.php?45037, https://savannah.cern.ch/bugs/index.php?44955
- shift in the reconstructed radial coordinate of the gamma conversion points
- PID
- eta dependency of PID efficiency: is it understood?
- PID efficiency at the relativistic rise: is the comparison data vs MC OK? Is the results understood? </ul</li></ul</li>
Calibration issues
- Online Calibration:
- status of the procedures (DAs, preprocessor)
- status of the DPs definition (new DPs foreseen, status of their implementation)
- run types defined for your preprocessor (are they correctly implemented in ECS / treated in your preprocessor?)
- status of the calibration objects (new objects needed?)
- Offline Calibration:
- status of the procedures after the Offline October '08 Week
- status of the calibration objects (new objects needed?)
- GRP:
- information you may need to have added in the GRP preprocessor
- run types for which you may need the GRP to run
- Trigger Information - in case your subdetector is a triggering detector:
- information you may need to retrieve
- procedures you may need to apply
- system (DAQ/DCS/HLT) you may need to interact with to retrieve your information
Trigger
there is one more item to be added to the planning of the detector offline that we should discuss together during the planning meeting. We need to have a precise trigger simulation along the following lines. For each trigger detector the configurable parameters of the trigger have to be stored into the OCDB. At simulation time, each trigger detector should have a trigger processor function that can be loaded with the configurable parameters and that, based on the configuration and on the recorded signal, should produce the corresponding input to the CTP as in real life. In parallel, the shuttle Trigger preprocessor should be extended so that it can read the trigger configuration parameters and store them into the OCDB. This means that each trigger detector should, in turn, make available these parameters on an appropriate File eXchange Server during data taking. During the planning meetings we would like to know how far is each of you from this scenario, what can reasonably be achieved and what is the timescale to get there. In particular we would like to have the list of the configurable parameters for each trigger detector and whether there are already trigger simulation functions that take them into account.
