Hi All,

    Below are my draft notes from the ALCPG simulation meeting
yesterday, March 27, 2007.  Any corrections or comments?

    For Fermi people: Since the first draft I have added:
2d), 4b) and 5 in the general comments section.  And I added
a few details to the work list at the bottom.

    Once we agree on these notes I will add them to the
material associated with the meeting in indico.

        Rob


Notes on the Fermilab groups presentation at the ALCPG
weekly simulation meeting, March 27, 2007.

There is a question for the general audience at the end.
There is a work list for FNAL people at the end.

[Rob's editorial comments in square brackets.]

General comments:

1) This proposed organization is relevant only for
    a detector built from planar sensor.  It is not
    intended to work with detectors represented by
    the cylindrical approximation.

2) a) At several points in the discussion Norman and
       Jeremy commented that the existing 64 bit cell
       ID was sufficient and that a separate sensorId
       was not needed.
    b) After the meeting I asked for a clarification on
       the 64 bit cell ID:
         i) It has the granularity to specifiy a single
            strip or pixel.
        ii) One can also extract from it the sensor on which that
            strip is located.
    c) We agreed to deal with this issue later.
    d) In a later discussions Dima suggested that, when we
       are designing this, we should consider the following
       problem: start from a set of SimTrackerHits, keep
       the position of all sensors fixed, but change the
       strip pitch, strip angles and other details of
       segmentation.

3) Jeremy asked if the hit objects might include a reference
    to the appropriate geometry object (subdetector?),
    instead of a sensorid.  The answer is yes but
    with two caveats:
       1) The reference needs to be persistable.
       2) We still need a way to say "give me all of the
          hit strips on a specified sensor" - so we need a
          language to specify a sensor. In the picture
          presented in this talk, this language is the sensorid.

4) Norm and Rich did not like the fact that there were many
    different types of objects that feed into the pattern
    recognition code (box 12):  clusters of strips, clusters
    of pixels, crosses of strip clusters and TrackerHits.
    Their suggestion is to create new classes for 1D and 2D
    measurements that obey the TrackerHit interface.  Then
    all of the inputs can be different sorts of objects that
    obey the TrackerHit interface.
      a) The Fermilab group will look into this but we are not yet
         convinced that the true commonalities outweigh the differences.
      b) After the meeting Dima commented that different pattern
         algorithms may expect different sorts of input - so it is
         probably inevitable that box 12 will have different sorts of
         input.  Therefore we need to manage the "which hit is on
         which track and which hits are free to use" bookkeeping
         in a way that allows several track finders can work together.

5) One point that did not get stressed enough in the presentation
    is that once a box is created, its contents are never modified.
    For example, if a pattern recognition code takes a hit from the
    cluster container (box 7) and modifies it, it should modify
    own copy, not the original hit.

Comments by page number:

Page 13, Re: Box 11 Container of TrackerHits
  - Nick's code uses global coordinates but otherwise his
    code has a lot of similarities.

Page 15, Box 13 Container of Tracks
   - Jan Strube has his own new and improved Track objects
     and should be included in this discussion.
   - The LCIO people need to be included.

Page 17, Re: Box 15 SimTrackerHits
   - These objects are made by SLIC and are the input for
     the org.lcsim processing of MC events.
   - SimTrackerHits are just stepping points from G4.
        - There are one or more of them for every
          MCParticle that traverses a sensor.
        - SimTrackerHits know nothing about whether
          a the sensor is a strip or a pixel or the
          pitch of strips/pixels.

Page 17, Re: Box 16 Algorithms to create RawTrackerHits
          from SimTrackerHits
    - Bruce raised a lot of questions about the processes
      of creating hit MC strips from SimTrackerHits.
         - All of those functions live in this box:
    - Nick's code for pixels is in cvs, some in production
      some in contrib.  See his talk from Feb 13.
    - Tim has done work on code for strips but it is not
      yet in cvs.

Page 17, Re: Box 17 Strips with non-zero pulse height.
    - Yes, these are RawTrackerHits.
    - The RawTrackerHit interface should be modified to
      return a list of MCparticles that contribute, rather
      than just a single MCParticle
         - This was an oversight in the original design
    - One can indicate a noise hit by returning a list
      of length zero.
    - There were two objections to storing the
      contribution of electronic noise:
         - The true picture includes crosstalk so it
           is much more complicated than suggested here.
         - Why would we want to include this? That information
           is not present in real data.
           [ We will want to study the quality of pattern
             recognition and track fitting under the
             constraint that we only consider "clean"
             clusters.  This is one way to disentangle
             diseases that are the inevitable results of
             noise from disease caused by bugs in the code.
             Also, what do we do if a pulse height
             is subtreshold amount from one MCParticle but
             a large amount of noise?  Do we return an empty list
             or do we say that all of the
             pulse height comes from the MCParticle? ]

Page 18.
   - Norman pointed out that there is already a class
     BaseTrackerHitMC that extends BaseTrackerHit, both
     of which obey the TrackerHit interface.
   - The same idea could be used here.
     [ However I would do a few things differently.
       BaseTrackerHitMC links back to SimTrackerHits,
       not RawTrackerHits.  So it has jumped a generation,
       cutting off the ability to follow the trail
       back along every step. Also there is no need to
       have both a list of MCParticles and a list of
       SimTrackerHits - the former can be obtained from
       the latter. ]

Page 21:
   - Bruce pointed out that the word FastMC is already used
     to mean something different.  We need to change our
     language to keep the ideas distinct from the existing
     ones.
   - Bruce already has code that does things similar to this.
     When we flesh this out we should be in contact with Bruce
     to make sure that we don't reinvent the wheel.

Page 28.
   - Norman says we definitely need to be in contact with
     other LCIO people but that calorimeter and muon people
     do not need to be involved.

Questions:
1) In existing code, do people instantiate BaseTrackerHit
    objects or BaseTrackerHitMC objects?


Work for FNAL people:

1) Understand if the 64 bit cell id can be made to work as
    a variant of the sensor Id.  If not provide specific
    reasons and an alternate solution.

2) Prototype classes for boxes 5, 7, 9.    Try to do it
    using 1D and 2D classes that implement the TrackerHit
    interface.  Look at Dima and Nick's work to make sure
    we include what they need.