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?
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?
IDDecoder
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.
Many in the room argued that getPosition() is not a function that should be supported by and ID decoder because a position cannot be determined
in a meaningful way by:
- a strip device
- a pixel device with clock to end of column readout
- a TPC hit
In cases 2 and 3 one can return a meaningful postion if one knows the correct beam crossing to use as time0. A strip device on its own
can never return a meaningful position.
Not everyone agreed with this point of view and argued that there are ways to hack a position in all cases ( assume midpoint of the unmeasured
coordinates).
I do think that there was agreement that on moving to a tracking specific IDdecoder.
Jeremy is working on an IDHelper that will provide useful functionality for parsing the ID's in the new geometry system. It does not implement
the IDDecoder interface.
The ID's as they are currently conceived in the new geometry system are not ID's for the entire detector, just for the tracking/vertexing systems.
Norman asked: if we go with the plans above, what happens if we want the Marlin people to read our simulated events. There was not a clear
answer on this: some people felt that is was not important for the Marlin people to be able to read hit level data but others did. We all agreed
that it was importand for them to be able to read our tracks.
Some general principles that were suggested at various times:
- We should separate objects that change from event to event from objects that are static throughout the job. For example geometry is static throughout the job and hits change from event to event.
- If the new geometry is designed to replace the old geometry, then we should remove from the API functionality that is not implemented in the new system.
- This may imply maintenance of code that used the old API.
- It would be good to be able to read event data without requiring that the geometry be instantiated. Of course there would be things that could not be done unless the geometry is instantiated.
- One solution is for the geometry to be instantiated on demand, as can be done with a singleton pattern.
Question/Work List:
- Propagate the setting of flag that controls the number of SimTrackerHits per track/sensor intersection so that it is accessible during reconstruction.
- Fix the bug in RawTrackerHit so that it returns a list of SimTrackerHits, not just a single one.
- Make a decision on the IDdecoder issues this week and implement it soonafterwards.
- What does it mean to have multiple events in memory and how is that handled? It is meaningful to merge events at any stage of the processing chain. ( If we want hits with high fidelity, it is important to make the hits before pulse heights are digitized. )
Matt Charles' talk
Needs to be copied from the Fermilab demo ILC docdb.