Just to add in my 2 cents…
> I lean towards a vertex based analysis model. That is really an event based model. A vertex is an actual collision, while a bunch crossing may contain 0 collisions, 1 collision, 2 collisions,
3 collisions, ....
I second this completely – in the data taking scenario where we have all sorts of backgrounds and we are trying to figure out where everything came from, the one “real” thing we can anchor on is a vertex as that corresponds to a real interaction.
I think classifying things in a hierarchical structure (e.g. clusters -> tracks -> vertices -> bunch crossings) will only help us keep things straight in the end.
---------------------------
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 2:24 PM
To: pinkenburg <pinkenburg AT bnl.gov>, sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: [EXTERNAL] Re: [Sphenix-tracking-l] Keeping track of bunch crossing
I am pretty confident that in the end we toss unassigned hits. Probably after multiple iterative seeding passes. But, after that,
unassigned hits are unusable when we do not know the bunch crossing. That can only be determined for hits assigned to TPC tracks that are in turn associated with silicon tracks. This is true for
both Au+Au and p+p. Keeping the unassigned hits makes no sense to me. Christof has looked into this for Au+Au, and thinks that we will toss most of the TPC hits in the end.
I lean towards a vertex based analysis model. That is really an event based model. A vertex is an actual collision, while a bunch crossing may contain 0 collisions, 1 collision, 2 collisions, 3
collisions, ....
The vertex object needs to carry the hooks needed to get all of the information required for a spin analysis. It would not hurt to try to define that soon.
From: pinkenburg <pinkenburg AT bnl.gov>
Sent: Wednesday, November 10, 2021 12:20 PM
To: Anthony Frawley <afrawley AT fsu.edu>; 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 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:
By event-by-event do you mean collision-by-collision?
Effectively, that is vertex-by-vertex, right?
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
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.
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
   
|
--
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.
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.
_______________________________________________ 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
*************************************************************
|
