Thoughts on ECAL ‘calibration stream’ D. del Re, P.Meridiani, R. Paramatti, Sh. Rahatlou, F. Santanastasio

Paolo Meridiani – INFN Roma1 2 Introduction Calibration is a key issue for ECAL it affects directly the energy resolution can limit the ECAL physics performance Several methods are foreseen to work in conjuction to obtain the final calibration coefficients:  -simmetry  0 /  0 W  e 2x10 33 after HLT ) Z → ee (1 2x10 33 ) Laser monitoring is not treated here since it is considered a special/separate monitoring task Methods can be divided in online calibration methods (which needs to access information before HLT decision) offline methods (which can work on standard HLT streams)

Paolo Meridiani – INFN Roma1 3 Motivation for a calibration stream Typically ECAL calibration tasks need access only to calorimeter hits in a particular area of interest (around the candidate electron/photon/pi0) Also access to fitted tracks/hits in a cone around candidate particle is needed Both offline and online calibration tasks need acces to a data format which should be be as light as possible In particular online calibration methods needs a filter application able which should run on the filter farm. Constraints on the readout rate / computation timings that CMS filter farm can devote to this type of job should be understood (question to filter farm experts)

Paolo Meridiani – INFN Roma1 4 ORCA electron calibration stream The ORCA calibration stream implementation was EgammaCalibObject,Level1Trigger,(EgammaMC) Package: ElectronPhoton/EgammaCalibObject (G. Daskalakis, P. Meridiani, P. Govoni) The EgammaCalibObject is constructed starting from each ElectronCandidate (L3 Candidate) and contains:  SC information (E,P T, ,  )  Associated track information (E,P T, , , number of valid hits, charge, trans. & longitud. impact parameter,…)  vector contained into an array (21-  x 11-  ) around the max. containment crystal MC truth (formatted as an EgammaMC object) was also available

Paolo Meridiani – INFN Roma1 5 phi eta energy CaloRecHit map 11 x 21 matrix

Paolo Meridiani – INFN Roma1 6 Past experience with ORCA In ORCA for the Physics TDR studies it was needed to further dump the information from the calibration stream to another format (ROOT or ASCII). This is infact one of the known problems of the past EDM Further data reduction means that afterwards you have no possibility of rereconstruction Physics TDR calibration studies on single electron and Z calibration however demonstrated that a single calibration stream type can be used for offline electron calibration

Paolo Meridiani – INFN Roma1 7 What will be in CMSSW Guideline (also following proposal from Y. Gerstein) should be to write just a subset of the existing collection e.g. a collection of EcalUncalibratedRecHits in a certain calorimeter area In principle no need to have a further data reduction step, since CMSSW data formats are lighter than ORCA and EDM is root based Clear advantage of reusing standard reconstruction algorithms (clustering, electron...) on reduced collection to process the calibration stream We only need filter modules which put into the event reduced collection of hits Conceptually the filter modules would be similar for calibration types.

Paolo Meridiani – INFN Roma1 8 Proposal for pi0 Currently understudy use of L1 objects to identify regions of interest for isolated pi0 sample Results to be shown at future egamma meetings Goal Select very small regions of ECAL containing pi0 Store only interesting crystals in output Perform clustering and pi0 selection on subset of crystal Perform in situ calibration with precision of ~1%

Paolo Meridiani – INFN Roma1 9 Pi0 Selection Based on L1 Objects Look at 4 L1 EM objects in barrel (  ) So far using QCD jets with 30<pT<170 Looking for hits inside a matrix of 20x20 around L1 object Non-overlapping by construction About 0.5  /matrix with E(  )>0.5 GeV Find 3x3 clusters within each matrix with seed xtal with E>0.5 GeV

Paolo Meridiani – INFN Roma1 10 Current Rate Estimate for Pi0 10kHz L1 input x 4 L1 EM objects x 0.5 [require N(xtal with energy in matrix) < 50] x 25 read in the 20 x 20 matrix (SR) x size of EcalUncalibratedRecHit (20 bytes)  10 MB /sec Estimate IF we want to include only Ecal information in the same format used by standard reconstruction

Paolo Meridiani – INFN Roma1 11 Additional Considerations for Pi0 Estimate No cluster level selection applied in current scheme before storing output If applied we could further reduce output rate Tracker information For the moment NO TRACKER information used to clean up or veto matrices Storing slice of tracker corresponding to L1 object desirable IF fits within allocated bandwith and disk budget Calib Format We strongly prefer using the reco data objects rather than new specialized ones

Paolo Meridiani – INFN Roma1 12 Electron calibration stream Logically electron calibration stream application seems to be well defined Calibration stream is produced offline starting from HLT single/double electron stream It will look at offline calibration electrons, having the possibility to apply electron id requirements to further reduce jet background Mantain calorimeter hits in a certain window around electron. Window size for calorimeter hits (in ORCA 11(  ) x 21(  ) ) can be further optimized. Need to answer which tracker hits to store Only hits associated to the electron track (allows simply refitting when new alignments are available) Hits in a “small” area around electron candidate (allows also to redo track building step with new alignments) Event size would be around 1-2 Kbyte x electron. Not critical as for pi0 calibration stream The same stream can be used both for single electron and Z calibration

Paolo Meridiani – INFN Roma1 13 Calibration application in CMSSW A calibration application needs typically to run over the calibration stream for more than one loop in one single job This possibility has been already taken into account by CMSSW framework developers, following a question on hypernews from P. Govoni

Paolo Meridiani – INFN Roma1 14 New EDLooper object Proposal from Chris Jones for an EDLooper ( As per the agreement from our conference meeting today, here is an API proposal for a new class of EDM 'module' which can be used to control 'multi-pass' looping over an input sources data.EDM class EDLooper { enum Status {kContinue, kStop} //called once per job just before the first processing virtual void beginOfJob(const edm::EventSetup&); //called each time just before starting to loop over the events in the source // the argument is the loop count, starting at '0' virtual void startingNewLoop(unsigned int ) = 0; //called for each event in the source virtual Status duringLoop(const edm::Event&, const edm::EventSetup&) = 0; //called after the last event in the source has been processed virtual Status endOfLoop(const edm::EventSetup&) = 0; //called just before the job is going to end virtual void endOfJob(); }; The EDLooper would also have the ability to add data to the edm::EventSetup, just like an ESProducer. This would allow one to change calibrations/alignments in the 'startingNewLoop' phase I also propose extending the configuration language to allow loading and configuring such EDLoopers looper = TrackBasedAlignmentLooper {.... } So classes inheriting from EDLooper would take an 'const edm::ParameterSet&' in their constructor which can be used to configure the looper.

Paolo Meridiani – INFN Roma1 15 Conclusions Guideline for CMSSW implementation of Ecal calibration stream would be to write filtered/reduced collection of hits Filter modules can start to be modeled. Electron stream is almost well defined, more thoughts are needed for pi0/eta0 We need to understand which are the constraints for data volume and computation time for a filter module running on the filter farm We have to also define which are the objectives for ECAL calibration in the CSA For example which datasets do we want to be simulated? Which exercises do we want to play?