LCD Simulation Reconstruction Meeting
Editorial comments in italics
Tuesday May 8, 2007 1:30 PM PDT
http://ilcagenda.linearcollider.org/conferenceDisplay.py?confId=1562
Ballam Conference room:
Norman, Hans, Tony, Jeremy, Nick, Matt Charles, Ron Cassel, Rich, Rob, Tim, Caroline, Dima
Tim's talk:
*Tim and Jeremy wanted to avoid a big heirarchy of xml files and keep it compact.
*GeomConverter creates the big geometry from the compact xml.
-
- big geometry used by both SLIC and org.lcsim
Did I get the description of the files correct?
.h2.About the multiplicity of SimTrackerHits:
When G4 propagates a track through a silicon detector, G4 may produce one or many G4 stepping points. This is under the control of various
material cut parameters in G4. There was a long discussion about the optimal choices for the cut parameters: the tradeoff is speed vs fidelity. Whichever is chosen, SLIC can be configured to create one SimTrackerHit for each stepping point or it can be configured to
create a single SimTrackerHit representing all of the G4 stepping points. In this latter case, the energy loss is the sum of the energy loss of summed over all G4 stepping points. I am not sure what the reported position and momentum are: but the are probably those values at one of the stepping points near the middle of the step through the material?
Can someone clarify this?
The choice of reporting one or many SimTrackerHits per track/detector pair is set in the compact geometry file but, at present, that information is not propagated so that it is accessable during reconstruction. It should be. In practice, with existing files, one may infer this information from the getPathLength() method of each SimTrackerHit, and if necessary, search for additional hits. In principle one must search the entire SimTrackerHits container.
Nick currently uses very small steps in his pixel code. He has files that were generated with 5 micron steps but not smaller. Nick has not
yet implmented with straggling in energy loss but he plans to.
Norman asked if the cylindrical geometry could be represented using this scheme. I don't remember the answer - does anyone?
There was a long discussion on whether not the IDdecoder should be something that gets returned by the RawTrackerHit or something else. The argument in favour of this is that users are guaranteed to get the correct IDDecoder. If they have to just know the correct IDDecoder, they will get the wrong one.
The present IDDecoder was mostly driven by the calorimeter people ( since they were out of the gate first?). At one time there were separate IDDecoders for calorimeters and trackers but some time ago they were merged into a single IDDecoder. We can undo that and define a tracking only IDDecoder if that makes sense.
If we move to separate IDDecoders, persist the objects, and read them back in, then how does the reader know which IDDecoder to attach to the hits? The answer needs to be provided in the meta data for the container that is stored in the event header. This is currently done for the calorimeter.
In the cvs head version of Jeremy's code, the IDDecoder will correctly parse the fields in the in the ID's that it finds and the methods that return field values will be correct. The rest of the functionality, in particular getPosition() is not yet working.