sPHENIX tracking discussion

[pinkenburg <pinkenburg AT bnl.gov>]

    Hi Tony,
    
    in our case this would be vertex by vertex. I haven't given this a
    lot of thought but I am worried that just passing tracks and
    vertices down to the analysis will make things unnecessarily
    complicated. Also more error prone since we have less control over
    downstream code in terms of making sure it does the right thing.
    
    But if this leads to massive data duplication (e.g. what do we do
    with unassigned hits? We cannot just save them in every one of those
    events), we need to think of something. 
    
    No matter what we do it will make changes in out input/output
    management necessary but I would take the approach that anything is
    possible, we just have to know what we want.
    
    Chris

On 11/10/2021 12:08 PM, Anthony Frawley wrote:

        Hi Chris,
      
        
      
      
        By event-by-event do you mean collision-by-collision?
      
        
      
      
        Effectively, that is vertex-by-vertex, right?
      
        
      
      
        Tony

---

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of pinkenburg via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Sent: Wednesday, November 10, 2021 11:52 AM
To: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: Re: [Sphenix-tracking-l] Keeping track of bunch crossing

 

Hi all,

we need to think more about the analysis which is not just tracks. This proposal here breaks the basic underlying assumption in our framework that you have only one event in memory (and replaces it by users doing the right thing). It's clear that we need to drop this assumption for the tracking itself but I am not to sure that we want to propagate this down into the analysis. Once we figure which track (and accompanying data/objects) belongs to which event (bunch crossing) it might be more advantageous for the downstream processing to save things event by event and not in one big blob

Chris

On 11/10/2021 11:03 AM, Dean, Cameron via sPHENIX-tracking-l wrote:

Hi all,

So in case b, the analysers would effectively cut on this vertex number and only keep the tracks associated to this bunch crossing? I would support this strategy as well because it keeps the disk space down but we should be mindful that the association has to be for all tracks in that collision and not just those associated to the primary vertex, i.e. we should ensure that if we cut on the vertex number we also keep the secondaries for that collision. This would be easier to achieve in case a but having some sort of tuple/dictionary will work for case b.

As a counter to my own point, we could tag secondaries to vertex ID 0 or -1 or something, assuming the number of secondaries is small compared to primaries and then just associate them to the PV with topological cuts at a later stage.

Cheers,
Cameron

 

From: "Osborn, Joe" <osbornjd AT ornl.gov>
Date: Wednesday, November 10, 2021 at 8:33 AM
To: Anthony Frawley <afrawley AT fsu.edu>, "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: Re: [Sphenix-tracking-l] Keeping track of bunch crossing

 

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

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

Christopher H. Pinkenburg	;    pinkenburg AT bnl.gov
				;    http://www.phenix.bnl.gov/~pinkenbu

Brookhaven National Laboratory	;    phone: (631) 344-5692
Physics Department Bldg 510 C	;    fax:   (631) 344-3253
Upton, NY 11973-5000

*************************************************************
      
    
    
-- 
*************************************************************

Christopher H. Pinkenburg	;    pinkenburg AT bnl.gov
				;    http://www.phenix.bnl.gov/~pinkenbu

Brookhaven National Laboratory	;    phone: (631) 344-5692
Physics Department Bldg 510 C	;    fax:   (631) 344-3253
Upton, NY 11973-5000

*************************************************************