Page History

LCD Simulation Reconstruction Meeting

Editorial Rob's editorial comments in italics

Tuesday May 8, 2007 1:30 PM PDT. Ballam Conference room.

Slides available at: http://ilcagenda.linearcollider.org/conferenceDisplay.py?confId=1562Ballam Conference room

Present: Norman, Hans, Tony, Jeremy, Nick, Matt Charles, Ron Cassel, Rich, Rob, Tim, Caroline, Dima

...

1. Propagate the setting of flag that controls the number of SimTrackerHits per track/sensor intersection so that it is accessible during reconstruction.
2. Fix the bug in RawTrackerHit so that it returns a list of SimTrackerHits, not just a single one.
3. Make a decision on the IDdecoder issues this week and implement it soonafterwards.
4. What does it mean to have multiple events in memory and how is that handled? It is meaningful to merge events at any stage of the processing chain. ( If we want hits with high fidelity, it is important to make the hits before pulse heights are digitized. )

Matt Charles' talk

...

Found a Bug in his Code

In his code he has a variable named doca for distance of closest approach. It is not the distance of closest approach of a track to a line. Instead it is the pathlength along the track from the current place to the point of closest approach ( to z axis, to vertex?). There was a bug in this computation. When it
was fixed, the jet energy resolution did not improve as much as expected.

Investigating the Poor Resolutions

The jet energy resolution estimated by simulation remain much poorer than expected, even when he used a pure cheater to perform all of the tracking.
He investigated and discovered that the problem was the following. Their code propagates tracks with the MC true parameters from the IP to the calorimeter face using an exact helix. For low momentum tracks this algorithm may miss the true impact point by many cm ( due to scattering
and energy loss ). Similarly when a track decays in flight, this calculation will give an incorrect answer. When this extrapolation misses the true impact point on the calorimeter by too much, then the track is not correctly matched to its calorimeter this and the PFA has poor energy resolution.

Matt's solution was to use the cheater to find the correct last 3 hits on the track, fit a helix to these hits and extrapolate it to the calorimeter. This improved things a great deal. There remain a small number of outliers that are due:

• The last three hits are a long distance from the calorimeter ( decay in flight ?)
• Bugs in correctly identifying the correct last three hits

In the followup discussion we agreed on part of the general solution to this situation. The reconstructed track class should provide the track parameters plus covariance matrices at many different points along the track, one of which should be at the outermost hit. The implementation should allow the parameters to be stored at an arbitary number of places. When track parameters are returned they should include information that says they are valid for some range of path lengths, relative to the reported point.

It is a detail for later to decide whether the standard tracking code should also extrapolate from the last hit to the face of the calorimeter or if that job should be left to the calorimeter code.

If the tracks are not correctly matched to clusters, shouldn't this systematically overestimate the jet energy since the track energy is counted twice? I remember that the resolution functions were fat but not biased? Did I misremember or is there another explanation?

The Fermilab MCFast algorithm would be the ideal solution to this problem: Cheat to find all of the hits on all of the tracks; for tracks with enough hits, kalman filter them both directions and store the track parameters at many places. This can be implemented using one of the existing kalman filters or perhaps with Nick's weight matrix fitter.

Rob's list of N places at which to store the track parameters + covariance matrix:

• Point of closest approach to the z axis.
• Point of closest approach to MC truth production vertex.
  • Very useful for resolution studies.
  • Only needed if this point is not within the beampipe vacuum.
• Innnermost hit.
• Outermost hit.
• Impact point on the face of the ecal or on some well defined surface close to the ECal.
  I would store all 5 by default and provide methods to drop unneeded parameter sets to save disk space, when they are not needed. I would also provide the option to store the full parameters at all measurement and scattering surfaces.