Hi Rob,

to answer your questions:
yes, I did instantiate BaseTrackerHitMC in few pieces of code.
Some of them are in contrib, some in production (FullCCDSimulation).
In every case I extended it, though, strictly speaking, I needed such
extension for debugging and for special tests. For general user applications,
it would be probably enough if I just instantiate BaseTrackerHitMC.

Nick

Robert K. Kutschke wrote:
> 
> 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.
> 
> 
>