sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
[Sphenix-tracking-l] Notes from sPHENIX tracking meeting march 20
- From: Anthony Frawley <afrawley AT fsu.edu>
- To: "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>
- Subject: [Sphenix-tracking-l] Notes from sPHENIX tracking meeting march 20
- Date: Wed, 21 Mar 2018 20:28:13 +0000
Hi All,
Here are some notes from our discussion at the tracking meeting yesterday.
Cheers
Tony
----------------------------------------
Darren: Did talk to Sookhyun since last meeting, but did not have time to work on association objects yet.
Sookhyun showed some slides (posted on the agenda page):
She asked if we should have an intermediate lightweight track object (in addition to TrkrTrack) like Alan's SimpleTrack3D, for use in seeding and track building. This kicked off a long and somewhat wide ranging discussion about efficiency.
It was noted that we are now planning to store clusters by detector element, so there is no reason that the clusterizer could not place the hit in the appropriate measurement plane and make the covariance matrix for it. The cluster key contains the index of the detector element in which it exists, so getting the normal vector for the plane, or transforming to global coordinates using the geometry object, is easy. However the track seeding and pattern recognition want a different, simpler cluster form than GenFit.
During the discussion we realized we need to make a summary of the copying/translation operations that are currently done in the tracking, so we can look at how to avoid them - perhaps consider a tradeoff with extra memory use.
We also decided it would be useful to compile a summary of the readout channel division for all detector elements. I agreed to do this for the TPC, Darren has it for the MVTX.
Christof commented that we will eventually want to do some parallel processing - even if only by using GPU's in the same box. We should be careful not to obviously exclude any options. We will ultimately be desperate for speed, and will want to optimize tracking in every way possible. Portability will be an early casualty, so we should not focus too much on it. We could potentially simplify TPC tracking quite a bit, since multiple scattering is small - don't need the full covariance matrix?
We should look at the new development version of the ATLAS code for clues. Christof is trying to get access to it.
We need to get a handle on how the effects of space charge distortion will be handled in tracking. Can we fix it once? At clustering time? We need to look ahead because it may affect how we can optimize tracking.
We eventually came back to Sookhyun's suggestion. We can have methods in the clustering that write the clusters in the measurement plane for GenFit, and a lighter object for use by track seeding and pattern recognition.
Haiwang showed some slides on memory profiling, where he ran 1000 and 5000 pion events. One surprise was a spike in memory when RAVE was getting the event vertex. But these events do not have a realistic pT distribution, and all of the high pT tracks will pass the cut for tracks used to get the event vertex. So that might be the cause.
Haiwang will try to do a Hijing event profile for next week.
Tony
----------------------------------------
Darren: Did talk to Sookhyun since last meeting, but did not have time to work on association objects yet.
Sookhyun showed some slides (posted on the agenda page):
She asked if we should have an intermediate lightweight track object (in addition to TrkrTrack) like Alan's SimpleTrack3D, for use in seeding and track building. This kicked off a long and somewhat wide ranging discussion about efficiency.
It was noted that we are now planning to store clusters by detector element, so there is no reason that the clusterizer could not place the hit in the appropriate measurement plane and make the covariance matrix for it. The cluster key contains the index of the detector element in which it exists, so getting the normal vector for the plane, or transforming to global coordinates using the geometry object, is easy. However the track seeding and pattern recognition want a different, simpler cluster form than GenFit.
During the discussion we realized we need to make a summary of the copying/translation operations that are currently done in the tracking, so we can look at how to avoid them - perhaps consider a tradeoff with extra memory use.
We also decided it would be useful to compile a summary of the readout channel division for all detector elements. I agreed to do this for the TPC, Darren has it for the MVTX.
Christof commented that we will eventually want to do some parallel processing - even if only by using GPU's in the same box. We should be careful not to obviously exclude any options. We will ultimately be desperate for speed, and will want to optimize tracking in every way possible. Portability will be an early casualty, so we should not focus too much on it. We could potentially simplify TPC tracking quite a bit, since multiple scattering is small - don't need the full covariance matrix?
We should look at the new development version of the ATLAS code for clues. Christof is trying to get access to it.
We need to get a handle on how the effects of space charge distortion will be handled in tracking. Can we fix it once? At clustering time? We need to look ahead because it may affect how we can optimize tracking.
We eventually came back to Sookhyun's suggestion. We can have methods in the clustering that write the clusters in the measurement plane for GenFit, and a lighter object for use by track seeding and pattern recognition.
Haiwang showed some slides on memory profiling, where he ran 1000 and 5000 pion events. One surprise was a spike in memory when RAVE was getting the event vertex. But these events do not have a realistic pT distribution, and all of the high pT tracks will pass the cut for tracks used to get the event vertex. So that might be the cause.
Haiwang will try to do a Hijing event profile for next week.
On Mon, Mar 19, 2018 at 1:32 PM, Anthony Frawley
<afrawley AT fsu.edu> wrote:
Hi All,
Let's resume our discussion of reorganizing the tracking simulations and reconstruction code tomorrow, at 10:15 am EDT. The agenda page is:
https://indico.bnl.gov/event/4418/
Let me know if you would like to post some slides.
Best regards
Tony
_______________________________________________
sPHENIX-tracking-l mailing list
sPHENIX-tracking-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l
-
[Sphenix-tracking-l] sPHENIX tracking meeting tomorrow, Tuesday March 20, at 10:15 am EDT,
Anthony Frawley, 03/19/2018
-
Message not available
- [Sphenix-tracking-l] Notes from sPHENIX tracking meeting march 20, Anthony Frawley, 03/21/2018
-
Message not available
Archive powered by MHonArc 2.6.24.