Minutes of the Monday Meeting, May 7, 2007.

Rob's Editorial comments are in italics.

When: Monday 1:30 PM
Present: Norman, Caroline, Dima, Hans, Jeremy, Rob, Tim, Jeremy

Candidate goals for this Week

This was copied from the whiteboard:

1. Define classes for tracking infrastructure
   • Flesh out Rob's diagram: http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=402
   • Make sure the relevant ideas from existing code are included.
2. Define a cheater for SimTrackHit to whatever it is that is used as input for pattern recognition.
   • Rob will do this once the endpoint is defined.
3. Re: links back and forth between Geometry and TrackerHits
   • Do we need full bidirectionality, as Jeremy has suggested, or is one way enough.
4. Re: Forward geometry.
   • Can Hans present a road map?
5. How does the above affect tracking algorithms?
   • This was written in response to Rob's comments that we need to resolve:
     • Cylindrical vs polyhedral issue.
     • Version control.

Dima's Geometry System

Dima showed some slides that were circulated by email.

The code discussed in these slides is available in: org.lcsim.contrib.onoprien.tracking.*

The original motivation for this code was for calorimeter assisted tracking in the forward region. The code uses both 1D and 2D readout. The code was developed some time ago but he has recently resurrected it.

When Dima wrote this code the geometry system was missing a lot of functionality. So he created it. With the recent work of Tim and Jeremy we have a much more functional geometry system. We now need to understand how to get one system from these two and make sure that it addresses everyone's needs.

Hans asked if this code supports alignment? Answer: it does not but it could.

Dima's code is flexible enough to store either hits on the cylindrical detector or hits on a polyhedral detector.

During the discussion it became clear that the word "Segmentation" was used in 2 different ways by various people in the room:

• The breakdown of a layer into sensors
• The arrangment of pixel/strips on a sensor
  The was lots of confusion when the speaker used segmentation in the second sense and some listeners assumed it was the first sense.

Aside: Another word that was used during the discussion, but not in Dima's talk, is "virtual segmentation". In this usage, segmentation is real if an object exists in the geometry system for each segment; for example there is an object to represent each wafer, about 10,000 to 20,000 in the vertex+tracking detectors. This, however, is not a practical solution for representing indvidual strips and pixels as there are too many of them. Instead there are objects that can compute which pixels or strips are hit given the intersection of a track with a silicon wafer; lists of hit strips and pixels are kept. This is refered to as virtual segmentation.

Dima's DigiTrackerHit:

• There is one digitracker hit per strip or per pixel.
  • It is possible for multiple MC particles to deposit energy on one strip. This bookkeeping is recorded internally to the digitracker hit.
    • Dima please check that I have this right.
• Units are deposited energy, in double precision.
• The pulseheight does not contain digitizer noise but one could add digitizer noise in the same way that two MCParticles might contribute to one strip.
• No ADC value is provided.
• No simulation of crosstalk is provided.

Comparing DigiTrackerHit to RawTrackerHit.

• DigiTrackerHit returns energy as a double , RawTrackerHit returns ADC counts as a short.
• DigiTrackerHit knows about multiple contributing MCPartilces; RawTrackerHit knows about a single contributing SimTrakerHit.
  • This is a long known bug in the RawTrackerHit interface that needs to be fixed. It should know about a list of contributing MCParticles.
• Both have access to geometry but via different mechanisms.

Dima's code understands the concept of dead material between layers.

I believe that the new geometry does not yet understand material between layers. Is that correct? Does the existing geometry for the cyclindrical sensors understand this?

Dima's track finding code operates on TrackClusters, not on TrackerHits. TrackClusters are never modified after they are created. It creates TrackerHits after it has associated a a cluster with a track. This is different than the original intended concept of a TrackerHit, as the object that feeds pattern recognition. This is the consistent with the plans of the Fermilab group and of Tim.

Comparing Dima's picture Rob's

The heading refers to data flow pictures. Dima's is on page 4 of his slides (attached) and Rob's is on page 8 of his slides: http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=402

• There are a lot of similarities in these pictures.
  • Dima's DigiTrackerHit box is conceptually similar to Rob's box 17
  • Dima's TrackerCluster class is conceptually similar to Rob's box 7.
• Dima's picture does not have the analog of box 5 in Rob's picture.
  • This represents a box that can be populated either by MC or by real data.
  • When populated by MC, it is intended to look exactly like real data.

Miscellaneous Points Made During the Discussions

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 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?