sPHENIX tracking discussion

["Osborn, Joe" <osbornjd AT ornl.gov>]

Hi Tony,

 

> Case b) would use less disk space. But it would possibly be more of a pain for analyzers to have to look up which vertex a track belongs to, and get the bunch crossing from that.

> On the other hand, perhaps all analyses will proceed vertex by vertex anyway, in which case, b) would be convenient enough.

 

I would be supportive of this strategy – I think analyzers will have to proceed vertex by vertex anyway given that this constitutes an “event” (in the sense of a single scattering). Tracks will have to be sorted on this basis anyway, so I think it makes sense since a vertex corresponds to some bunch crossing.

 

I also agree with Ming that it would make sense to sort the vertices by spin orientation also since the beam spin orientations are on a bunch crossing basis. This would then have an organization of tracks associated to a vertex, which are associated to a bunch crossing/spin pattern.

 

Joe

 

---------------------------

 

Joe Osborn, Ph.D.

Associate Research Scientist

Oak Ridge National Laboratory

osbornjd AT ornl.gov

(859)-433-8738

 

 

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Anthony Frawley via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Date: Wednesday, November 10, 2021 at 12:53 AM
To: Liu, Ming Xiong <mliu AT lanl.gov>, sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Cc: Dean, Cameron <cdean AT bnl.gov>, Shi, Zhaozhong <zhaozhongshi AT lanl.gov>, Yasser Corrales Morales <yasser.corrales.morales AT cern.ch>
Subject: [EXTERNAL] Re: [Sphenix-tracking-l] Keeping track of bunch crossing

Hello Ming,

 

My understanding is this:

 

The reconstruction will be event based, where "event" refers to a triggered event. For p+p, the expectation is that the TPC readout (and other tracking readouts) will be extended by some time after each trigger (7 μs, nominally) to also collect MB events that are fully contained in the TPC. So each event will contain one triggered event in crossing zero, and roughly 15 MinBias collisions (at 2 MHz) in crossings 0-70.

 

There will also be many tracks from crossings (-150 to -1) and (71 to 220) that are outside the 7 μs window where the TPC will read out complete events. The efficiency for reconstructing those events will drop as the crossing gets further away from 0-70.

 

So we definitely need to record the crossing number. The question is: where?

 

We have to do the track reconstruction before can determine the bunch crossing for each track. After the reconstruction, we can organize the data into collision vertices, each with the bunch crossing identified.

 

It sounds like we will need to have both the bunch crossing and the related spin information in the vertex object. The vertex object also has a list of associated tracks.

 

Tony

 

---

From: Liu, Ming Xiong <mliu AT lanl.gov>
Sent: Wednesday, November 10, 2021 12:05 AM
To: Anthony Frawley <afrawley AT fsu.edu>; sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Cc: Yasser Corrales Morales <yasser.corrales.morales AT cern.ch>; Dean, Cameron <cdean AT bnl.gov>; Shi, Zhaozhong <zhaozhongshi AT lanl.gov>
Subject: Re: [Sphenix-tracking-l] Keeping track of bunch crossing

 

Hi Tony and all,

 

For pp (and pA), are we going to have bunch crossing based event structure that contains all the vertices and tracks, or not?

I think for spin related analyses, we also need to have beam-xing related spin information.  

 

Cheers,

Ming

 

PS – did I tell you we could make a short presentaiton about new MVTX data format next week ?  

 

-----

Dr. Ming Xiong Liu P-3, MS H846 Physics Division   Office: 505.667.7125 Mobile: 505.412.7396 Los Alamos National Laboratory lanl.gov

-- 

 

 

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Anthony Frawley via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Reply-To: Anthony Frawley <afrawley AT fsu.edu>
Date: Tuesday, November 9, 2021 at 9:28 PM
To: "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>
Subject: [Sphenix-tracking-l] Keeping track of bunch crossing

 

Hi All,

 

In pp running we will want to keep track of bunch crossing number for every track. At the least, we need to know if the track was in an event that is fully contained in the TPC.

 

We could either:

a) add a signed int to the track object.

b) add a signed int to the vertex object.

 

In case b), the bunch crossing would have to be kept in a map on the node tree for all tracks, so that the final vertexer could look it up and add it to the vertex object.

 

Case b) would use less disk space. But it would possibly be more of a pain for analyzers to have to look up which vertex a track belongs to, and get the bunch crossing from that.

 

On the other hand, perhaps all analyses will proceed vertex by vertex anyway, in which case, b) would be convenient enough.

 

For context, a pp event with 7 microseconds additional readout time will have ~ 15-20 vertices from events fully contained in the TPC. These will be distributed over ~ 70 bunch crossings.

 

Thoughts?

 

Tony

 

 

_______________________________________________ sPHENIX-tracking-l mailing list sPHENIX-tracking-l AT lists.bnl.gov https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l