Thoughts on ECAL ‘calibration stream’

Thoughts on ECAL ‘calibration stream’

D. del Re, P.Meridiani, R. Paramatti, Sh. Rahatlou, F. Santanastasio

Paolo Meridiani – INFN Roma1 2

IntroductionCalibration 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:-simmetry0/0 •We (10Hz @ 2x1033 after HLT )•Z → ee (1 Hz @ 2x1033)

Laser monitoring is not treated here since it is considered a special/separate monitoring taskMethods can be divided in • online calibration methods (which needs to access information before HLT decision) • offline methods (which can work on standard HLT streams)


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)


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,PT,,)Associated track information (E,PT,,, number of valid hits, charge, trans. & longitud. impact parameter,…) vector<CaloRecHit> contained into an array (21- x 11-) around the max. containment crystal

MC truth (formatted as an EgammaMC object) was also available


phi

eta

en

erg

yCaloRecHit map

11 x 21 matrix


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


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.


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%


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


Current Rate Estimate for Pi0

10kHz L1 inputx 4 L1 EM objectsx 0.5 [require N(xtal with energy in matrix) < 50]

x 25 <xtals> 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


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


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


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


New EDLooper object Proposal from Chris Jones for an EDLooper (

https://twiki.cern.ch/twiki/bin/view/CMS/FwEdmProposalForMultiplePassesPerJob)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. 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.

https://twiki.cern.ch/twiki/bin/view/CMS/FwEdmProposalForMultiplePassesPerJob

https://twiki.cern.ch/twiki/bin/view/CMS/EDM


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 2006. For example which datasets do we want to be simulated? Which exercises do we want to play?

Documents

Thoughts on ECAL ‘calibration stream’