C. Seez Imperial College November 28th, 2002 ECAL testbeam Workshop 1 Pulse Reconstruction Worth...

November 28th, 2002

ECAL testbeam Workshop1

C. SeezImperial College

Pulse ReconstructionPulse Reconstruction Worth considering the experience of other experiments

using sampling ADCs The problem:

Obtain a single number from digitized time-samples CMS ECAL test beam:

Asynchronous ~12 time samples (or less) TDC measurement of phase is available Pulse shape of laser and beam ~significantly different (?)

CMS experiment at point 5 10 time samples Synchronous for interaction data Poorly synchronous (~8ns jitter) for laser data (TDC available?)

November 28th, 2002



Experience elsewhereExperience elsewhere A standard problem in precision calorimetry…

Reconstruct from time samples minimizing the noise contribution Universally solved using “digital filtering” (linear weighting) Most of the fuss gets made when the noise sources are complicated

(pileup etc) Examples: Babar (asynchronous), NA48 (asynchronous), ATLAS

(same as us)

Guillaume Unal has kindly allowed me to show transparencies from a recent presentation on NA48

NA48 uses 40 MHz clock and has ~70ns pulse width

November 28th, 2002



(i.e. how many samples)

November 28th, 2002



November 28th, 2002



Issues for CMS ECALIssues for CMS ECAL The issues needing work are the precise details of the

implementation How define the weights? Is there an advantage in using phase measurement from pulse rather than from

TDC? Event by event pedestal subtraction, or pedestals from pedestal runs? How many samples should be used? Do we need a separate sets of weights for each 1ns bin of phase?

Or use a correction function, f(t) ? Are channel-to-channel pulse width variations so large as to require more than

one set of weights? NA48 uses 11 sets for >10ns variation in pulse rise time

What is the relationship to the final method used in CMS? Variation of intercalibration with (details of) the method Variation of linearity with (details of) the method

What is the simplest way to deal with (event-to-event, or run-to-run) laser pulse-width variations?

Different set of weights for each of ~10 width bins? What should we use for the PN’s of the laser system?

Should not be hard to define an optimal set of weights

November 28th, 2002



What is needed from pulse reconstruction?What is needed from pulse reconstruction? No compromise on performance

Except, perhaps, if really necessary, for Online Speed and simplicity

Speed: can we work directly from raw data without penalty? Simplicity:

how much needs to be set up — constants, parameters, data files, pulse-shapes etc etc — before the algorithm can be run?

If setting up is necessary, can it be automated? In general: every set of constants that needs to be determined and

setup afresh each time a new SM is put in the beam implies an automated task that must be designed and tested…

In 2004 we have to be ready to “push the button” Understanding

Must understand the ‘error’ (cf NA48: 0.85 x single sample noise) Must be able to rapidly extract the error/noise from pedestal runs Simulation should be used to confirm consistency of results

November 28th, 2002



SimplicitySimplicity Ultimate simplicity

One set of weights for all channels, and one phase correction function One set of weights for each 1ns bin of phase, but used for all channels (almost

as simple) Different sets of weights for different channels implies a “preparatory task” of

determining which channel uses which set of weights Extraction of weights should be separated entirely from their use

The actual reconstruction should be as simple as possible, so that we can do it on-the-fly

Worth trying for ultimate simplicity, even if it is necessary to complicate it when we understand the limitations

Compare with NA48: 11 sets of weights for each 1ns bin of phase…

For every “complication” that requires a first pass through the data to derive constants and tunings, there has to be a robust automated procedure…

In the NA48 case one needs to determine which of the 11 sets of weights are appropriate

November 28th, 2002



Pedestal subtractionPedestal subtraction

Except in the case of large low frequency pick-up noise, it is better to subtract mean pedestals calculated from a pedestal run, rather than use event-by-event pedestal determination (if N samples are used for pedestal determination there is a contribution of single/N)

Price: pedestal runs must be analysed before pulse extraction can proceed Need robust automated procedure Pedestal stability needs to be understood

November 28th, 2002



Special problems this yearSpecial problems this year Because of huge electronic noise, and its

characteristics, 2002 data may be a poor guide to: How sensitive we are to precise details of how the weights are defined Noise/resolution vs number of samples

Two sub-modules with phase-shift Chans (1-5, 11-15) by +½ clock; Chans (21-25, 31-35) by –1 clock Must be checked and corrected before H4 data taking in future

Not clear whether 2002 data is useful as a test-bed to design the extensions of the algorithm needed for reconstructing multi-range pulses (free gain mode)

November 28th, 2002



How to proceed?How to proceed? “Which is the best?” among N competing complete

packages is not the optimum way forwards… Goals must keep in mind the whole picture — in particular the needs

of pre-calibration in 2004 We will not make best progress by a too rigid definition of the

“requirements” at this stage Development has to be an iterative interaction between a

responsible/coordinator and a group of developers

Need to agree on a direction, and then to investigate the details; for example:

Peak wrt TDC varies from channel-to-channel — just due to rise-time? How much does width of beam pulses vary channel-to-channel? Does it

matter? Just rise-time variation? How to best handle laser (event-to-event) pulse width variation? Use a

digital filter to measure pulse width?; and use this measurement to correct (or to choose an appropriate set of weights)?

November 28th, 2002



SummarySummary Digital filtering is the way to go The issues that need to be resolved concern the

precise details of the implementation How much simplification and universality can be

achieved without sacrificing performance? In particular (for 2004):

Aim to minimize the number of preparatory (robust, automated) tasks that need to be run before the ‘final numbers’ can be extracted

Do we need different sets of weights for different channels? Or can we have everything ready before we have taken any data on a super-module?

We probably can’t answer these questions fully with this year’s data, but such a goal should guide the questions we ask and the framework we put in place for 2003

C. Seez Imperial College November 28th, 2002 ECAL testbeam Workshop 1 Pulse Reconstruction Worth...

Documents

Transcript of C. Seez Imperial College November 28th, 2002 ECAL testbeam Workshop 1 Pulse Reconstruction Worth...