Page History

...

1. Nick: it's OK if we change TrackerHit but please just do it once.
2. Nick is currently forced to check if covariance(z,z)=0 to check if a TrackerHit is barrel or endcap! So he welcomes better tools.
3. Tim asked: consider the intersection of some track with the plane that contains a sensor. Who is responsible for deciding if the intersection point is within or outside the instrumented region of the sensor? We need to understand which code is responsible for this and how that condition is indicated. He drew an example of a stereo strips sensor in which the strips are not parallel to any edge. Remember too that sensors are not necessarily rectangles.
4. How do we address a simple bookkeeping issue related to the following problem:
   • a) Run G4 once to create SimTrackerHits.
   • b) Run reconstruction many times varying things like, strips vs pixels in forward region near the beam pipe, strip pitch, dead areas, single-bunch timing or not.
   • Options:
     1. i) At present the only place to encode parameters for b) is in the xml file. So we could create multiple xml files, differing only in their b) information. But this breaks the model that you reconstruct using the same xml file used for simulation; or you waste resources rerunning MC.
     2. ii) Variant on previous option. Assert that the information in b), present in the xml file, are default values, permitted to be overridden by hand coding SetXXXX() calls in the driver. This implies that we need to create a mechanism to record what was overridden.
     3. iii) Store the information b) in a conditions data base.
     4. iv) Store the information b) in a run-time config file.
   • Most people prefered some variant on iii) or iv). Jeremy was advocating ii).
5. In conjunction with 4), Norman pointed out that we should have an automated method for recording what versions of what code and what run time configuration information we used for a given run of the reconstruction code. At present the simulation records this information in the LCIO file. We have talked about doing the same for reconstruction but have not yet done it.
6. Re: the ongoing saga about whether the new code will work with the cylindrical geometry or just the polyhedral geometry. We narrowed the question down a little. The question is whether all pattern recognition codes should be required to work with both. We did not reach an agreement on this but we did agree that the supporting tools should work with whichever geometry is present.
7. Re: the IDecoder in Jeremy and Tim's new code. This is something new, not a variant of the 64 bit cell ID. It might be as simple as an integer 0....(N-1) where N is the number of sensors in the detector. This is similar to what Rob and Hans envisaged and similar to the internals of Dima's geometry system. So it looks like we are all on the same page about this.
   • The IDDecoder issue was discussed at length on Tuesday Wednesday.

For Tomorrow:

1. Are we really all on the same page about miscellaneous item 7)?
2. Get presentations from Dima, Nick, Rob, Norman(TRF) ( anyone else ) about what is in/(needed in) a cluster class.
3. In light of 2, what is the fate of TrackerHit?