ALCPG Sim/Reco Weekly Meeting: SimTrackerHit to TrackerHit discussion
→
US/Pacific
Description
Time: 13:30 Pacific Time US (UT -8)
Connection Information:
Call: 510-665-5437 Meeting ID: 0873
Participation:
Please be prepared to participate via the ecs shared desktop.
Instructions can be found at:
http://confluence.slac.stanford.edu/display/ilc/Connecting+via+ESnet+Collaboration+Service
Mailing List:
lcd-dev
self-subscribe at:
http://www.slac.stanford.edu/cgi-bin/lwgate/LCD-DEV/subscribe.html
-
-
1
Some Thoughts on Hits, Geometry ...Speaker: Dr Robert Kutschke (Fermilab)SlidesNotes on the presentation by the Fermilab group 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? - Nick replied that does sometimes use BaseTrackerHitMC but usually uses his own classes that include extra information not present in BaseTrackerHitMC. He plans to use BaseTrackerHitMC in code he makes public and thinks it is probably sufficient. 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.
- 2
-
1