• Created by Unknown User (kutschke), last modified on May 11, 2007

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Thursday, 9:00 AM, Sierra conference room

Hans, Tim, Norman, Jeremy, Caroline, Nick, Rich, Dima, Rob

Tony's showed his Use Cases wiki page

  • He wants us to add use cases to this page.

We noted that a cluster can have a gap in it if a strip is know to be bad dead or hot. For now clusters will be contiguous but we anticipate that
we will need to have non-continguous clusters at a later date.

Jeremy:

  • Virtual segmentation of sensors is not yet "canonicalized".
    • Virutal segmentation means tiling the surface of a sensor with pixels and strips. For example, the geometry system might hold one very long strip sensor. It might be broken up into several shorter strip sensors for purposes of assiging a hit to a readout channel.
  • A Sensor is a specialized DetectorElement.

Rob mentioned the issue of the histogram code in the example to access the SimTrackerHits.

  • Tne example is appropriate for the purpose of showing how to access this data.
  • The example teaches new users a way to fill histograms that is elegant in that it is all done in a single line of code
  • However if a users follows this model to create and fill many histograms, the resulting code can be very slow because aida has to search for the right histogram to fill based on the string identifier.
    • The group welcomes additional examples that show methods that execute faster.
  • Tony mentioned that the search for which histogram to fill is optimized:
    • In many loops histograms get filled in the same order in each pass.
    • So aida's search algorithm is: if I just filled histogram h1, and usually after h1 I fill h2, then on the next call to fill a histogram I will first look to see if the requested histogram is h2.

Tony has calorimeter clusterers that are intended to work with a wide range of geometries, so long as the geometries support certain features. He
wants to make sure we include these features. I missed some of the detail.

This lead to a broad discussion about one geometry element knowing its neighbours and how this should be implemented. Lots of it was calorimeter oriented. For example, What if the neighbouring cell is on a different detector element?

  • Tim: This problem is in the plan but it is not yet implemented.
  • The general algorithm might need to go up one level in the geometry heirarchy to solve this.
  • What API needs to exist?
  • Not a problem for tracking since the resolution of a hit is large compared to the gaps betweeen neighbours. But it is important in calorimetry.

Rich showed a new candidate for the cluster class.

  • It forwarded a lot of geometry functions that we agreed to remove.
    • Just provide access to the geometry instead.
    • The stripped down class was shown in the afternoon session ( below ).
  • We agreed that the getResidual() method did not belong. It belongs in a class with many more features.
  • Tim did not want to provide a "getStripLength" feature since it can have a poorly defined meaning for a cluster.

Norman showed some TRF stuff:

  • All tracks are fitted presuming the pion mass for energy loss and scattering.
    • There is no option to use a different mass.
  • Still needs the bridge code to instantiate its geometry from the org.lcsim geometry.
    • Should be simple once that is decided.
  • Language: hits and misses
    • hit can have material associated with it.
    • miss is material without a hit ( eg. beam pipe, inefficient detector .... )
    • Point of closest approach to origin is one type of miss.
  • He showed his hit class:
    • to use TRF you instantiate TRF hits from the clusters in the event.
  • Native output includes track parameters + cov at all hits and misses.
    • No persistency yet
    • He wants to shoehorn his Hit class into TrackerHit.
  • He allows kinks on tracks.
    • I am not sure what this is for.
  • Cylinders for PCAO style tracks are always coaxial with the z axis
  • Planar surfaces are always perfectly alighned but we could make new hit derived classes to fix that when needed - not a problem.
  • He implements both thickscatter and thinscatter materials
  • Straggling in energy loss does get into the covariance matrix.
  • At the Saclay meeting last week, Ties presented a trajectory class that could hold track parameters + cov at multiple locations. Others prefered extending the existing Track class.
  • No labels