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
Tim's talk:
- Tim and Jeremy wanted to avoid a big heirarchy of xml files and keep it compact.
- GeomConverter creates the big geometry from the compact xml.
- big geometry used by both SLIC and org.lcsim
Did I get the description of the files correct?.h2.
About the multiplicity of SimTrackerHits:
When G4 propagates a track through a silicon detector, G4 may produce one or many G4 stepping points. This is under the control of various
material cut parameters in G4. There was a long discussion about the optimal choices for the cut parameters: the tradeoff is speed vs fidelity. Whichever is chosen, SLIC can be configured to create one SimTrackerHit for each stepping point or it can be configured to
create a single SimTrackerHit representing all of the G4 stepping points. In this latter case, the energy loss is the sum of the energy loss of summed over all G4 stepping points. I am not sure what the reported position and momentum are: but the are probably those values at one of the stepping points near the middle of the step through the material?
...
Norman asked if the cylindrical geometry could be represented using this scheme. I don't remember the answer - does anyone?
IDDecoder
There was a long discussion on whether not the IDdecoder should be something that gets returned by the RawTrackerHit or something else. The argument in favour of this is that users are guaranteed to get the correct IDDecoder. If they have to just know the correct IDDecoder, they will get the wrong one.
...
- Propagate the setting of flag that controls the number of SimTrackerHits per track/sensor intersection so that it is accessible during reconstruction.
- Fix the bug in RawTrackerHit so that it returns a list of SimTrackerHits, not just a single one.
- Make a decision on the IDdecoder issues this week and implement it soonafterwards.
- 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.