Skip to Content.
Sympa Menu

sphenix-tracking-l - Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion

sphenix-tracking-l AT lists.bnl.gov

Subject: sPHENIX tracking discussion

List archive

Chronological Thread  
  • From: "Bertaux, Joseph Tyler" <jbertau AT purdue.edu>
  • To: "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>
  • Subject: Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion
  • Date: Thu, 18 May 2023 14:41:45 +0000

Hello,

Hopefully I can help clarify.

I don't think the request is to modify the .evt or stream structure, but on the offline reconstruction side. Tony might have used the wrong word in the original email—the streams contain the full information and I don't think we need to modify those.

The idea was to have intermediate structures on the offline reconstruction side that mimic the role of the headers we'd encounter in the streams. As I understand, the current hitkeys have 32 bits which are usually used for a subdetector address and a timing offset relative to the BCO clock at the start of an event (or at least, that is the INTT's case).

However, we need a place to store "wider" fields (full BCO, trigger word) that will be common to a long list of subsequent hits, so the TrkrHitSet objects don't have to be modified to store twice what they already do to hold a redundant value. It's very likely that such infrastructure already exists, but if it does not it may need to be created.

An example workflow is to have a TrkrEvt class, which has members for the "wide" fields (BCO, trigger) and a TrkrHitSet object to store the hits. Then creating a TrkrEvtSet class (analogous to TrkrHitSet), which can iterate through hitkeys by either going to the next key in the current TrkrEvt's member TrkrHitSet, or going to the first key in the next TrkrEvt in a member list of TrkrEvts. Iterating gives a sequence of hitkeys which most codes are likely already designed to use, but at any time you can get the "wide" fields from the current TrkrEvt instance (the member iterator class should have the current hitkey and the current TrkrEvt).

Joseph

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Martin Purschke via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Sent: Thursday, May 18, 2023 8:17 AM
To: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion
 
---- External Email: Use caution with attachments, links, or sharing data ----


Tony,

help me understand what this adds that cannot be done from the original
input files.

The substems that you flag here have the BCO embedded in the stream, AND
(different from PHENIX), the data in our files are strictly  in BCO/time
order. So as you go, you hit a BCO from the GL1, and see who is on board
with the same (or very close with +- x ticks) with that.

Here is a GL1 file from our first collisions from last night. There were
no tracking detector with their own BCO value on board yet last night,
but you get the idea. You see the full 64bit BCO here (the others have
the lower 40 bits of that embedded):

> $ ddump -i -n 10 -e 3 /bbox/commissioning/GL1/junk/*7052*
>  -- Event     3 Run:  7052 length:   512 type:  1 (Data Event)  1684393640
> packet nr:   439684772
> Beam Clock:  3708570699185
>
> Trg #                  raw             scaled               live
> ----------------------------------------------------------------
>   0                    972                972                  0
>   1                     11                 11                  1
>   9                     10                 10                  0
>  11                      5                  5                  0
>
>  -- Event     4 Run:  7052 length:   512 type:  1 (Data Event)  1684393640
> packet nr:   439684773
> Beam Clock:  3708570699829
>
> Trg #                  raw             scaled               live
> ----------------------------------------------------------------
>   0                  13716              13716                  0
>   1                     22                 22                  2
>   9                     21                 21                  0
>  11                     15                 15                  0
>
>  -- Event     5 Run:  7052 length:   512 type:  1 (Data Event)  1684393640
> packet nr:   439684774
> Beam Clock:  3708570700592
>
> Trg #                  raw             scaled               live
> ----------------------------------------------------------------
>   0                  14360              14360                  0
>   1                     33                 33                  3
>   9                     32                 32                  0
>  11                     22                 22                  0
>
>  -- Event     6 Run:  7052 length:   512 type:  1 (Data Event)  1684393640
> packet nr:   439684775
> Beam Clock:  3708570701535
>
> Trg #                  raw             scaled               live
> ----------------------------------------------------------------
>   0                  15123              15123                  0
>   1                     44                 44                  4
>   9                     43                 43                  0
>  11                     28                 28                  0

...

Chris has demonstrated many times that we can read the streams together
without any problems.

This file is not taken at the same time, so the BCOs have nothing to do
with the above, but here is an example what the INTT has to say. You see
the hits associated with a given BCO, and that the BCOs increase
monotonically:

> $ ddump -n 10 /mac_home/data/INTT/intt_intt0-00005988-0000.evt
> Packet  3001   132 -1 (sPHENIX Packet) 110 (IDINTTV0)
>   Number of hits: 10
>    #    FEE    BCO      chip_BCO  chip_id channel_id    ADC  full_phx full_ROC Ampl.
>    0    13  d987ea1263   0x63       6         1         0     0         0       0     0x03010063
>    1    13  d987ea1263   0x63       7        44         1     0         1       0     0x23ac0163
>    2    13  d987ea1263   0x63       6        13         1     0         0       0     0x230d0063
>    3    13  d987ea1263   0x63      25        26         0     0         1       0     0x0c9a0163
>    4    13  d987ea1263   0x64      26        30         0     0         0       0     0x0d1e0064
>    5    13  d987ea1263   0x64      26        33         0     0         0       0     0x0d210064
>    6    13  d987ea1263   0x64      22        75         0     0         0       0     0x0b4b0064
>    7    13  d987ea1263   0x66      23        58         1     0         0       0     0x2bba0066
>    8    13  d987ea13a3   0x23      20        75         2     0         0       0     0x4a4b0023
>    9    13  d987ea13a3   0x23      21        74         2     0         0       0     0x4aca0023
> Packet  3001    68 -1 (sPHENIX Packet) 110 (IDINTTV0)
>   Number of hits: 4
>    #    FEE    BCO      chip_BCO  chip_id channel_id    ADC  full_phx full_ROC Ampl.
>    0    13  d987ea14e3   0x64      22        73         0     0         0       0     0x0b490064
>    1    13  d987ea14e3   0x65      26       127         0     0         1       0     0x0d7f0165
>    2    13  d987ea14e3   0x63      22       109         0     0         1       0     0x0b6d0163
>    3    13  d987ea14e3   0x63      24       103         0     0         1       0     0x0c670163
> Packet  3001    68 -1 (sPHENIX Packet) 110 (IDINTTV0)
>   Number of hits: 0
>    #    FEE    BCO      chip_BCO  chip_id channel_id    ADC  full_phx full_ROC Ampl.
> Packet  3001    68 -1 (sPHENIX Packet) 110 (IDINTTV0)
>   Number of hits: 33
>    #    FEE    BCO      chip_BCO  chip_id channel_id    ADC  full_phx full_ROC Ampl.
>    0    13  d987ea1763   0x63       7        37         0     0         0       0     0x03a50063
>    1    13  d987ea1763   0x65       6        31         4     0         0       0     0x831f0065
>    2    13  d987ea1763   0x63      21        39         0     0         0       0     0x0aa70063
>    3    13  d987ea1763   0x64      25         8         0     0         1       0     0x0c880164
>    4    13  d987ea1763   0x66      24        18         0     0         1       0     0x0c120166
>    5    13  d987ea1763   0x64      19         5         3     0         1       0     0x69850164
>    6    13  d987ea1763   0x64      20        31         1     0         1       0     0x2a1f0164
>    7    13  d987ea1763   0x64      19        82         5     0         1       0     0xa9d20164
>    8    13  d987ea1763   0x65      19         6         2     0         1       0     0x49860165
>    9    13  d987ea1763   0x65      19        30         5     0         1       0     0xa99e0165
>   10    13  d987ea18a3   0x23      22        78         0     0         0       0     0x0b4e0023
>   11    13  d987ea18a3   0x25      22        48         0     0         0       0     0x0b300025
>   12    13  d987ea18a3   0x25      22        12         0     0         0       0     0x0b0c0025
>   13    13  d987ea18a3   0x25       7        85         0     0         0       0     0x03d50025
>   14    13  d987ea18a3   0x26      19        74         0     0         1       0     0x09ca0126

I must be missing something, because I think this does exactly what you
are asking for?

I was on my feet the night for the first collisions and need to take a
break, but maybe we canget on the horn later?

`- Martin


On 5/17/23 21:49, Anthony Frawley via sPHENIX-tracking-l wrote:
> Hi All,
>
> We had a discussion in the tracking software meeting this morning about
> what should be put in the data stream by each of the tracking detectors
> to forward the needed information to the track reconstruction code. Here
> is a brief summary of the results:
>
> We picture three stages:
>
>  1. An intermediate file is written by each subsystem.
>  2. An "event builder" picks up the intermediate files and creates an
>     event-based file.
>  3. The event-based file is read into Fun4All and tracks are reconstructed.
>
> The primary goal today was to define what must be in the intermediate
> files, stage 1 above. For a discussion of step 2 we need other experts
> present. The general expectation is that there will be an event header
> for each assembled event that contains (at least) the GL1 trigger word
> and the full BCO times for each subsystem. Then the relative time
> offsets can be put in the hitset key for each subsystem.
>
> For triggered data:
> -------------------------
> MVTX (Yasser):
> GL1 trigger time
> Full BCO start time for each strobe
> Hitsets for each strobe
> (The event header created later will contain the full GL1 and BCO times)
>
> INTT (Joseph B):
> GL1 trigger time
> Full BCO time
> Hitsets for each BCO
> 7 bit offset from GL1 time and address of hit in the hitset key
> (The event header created later will contain the full GL1 and BCO times)
>
> TPC (Jin and Takao):
> GL1 trigger word
> BCO start of time frame
> Hitsets
>
> TPOT (Hugo):
> (Just like TPC in triggered mode)
> GL1 trigger word
> BCO start of time frame
> Hitsets (Hugo: one hit will be selected from the time stream and kept).
>
> There may be a need for changes to the hitset key structure by each
> subsystem. This should be made as a proposal and discussed beforehand,
> since there is potential for disruption when changing these.
>
> The question was asked "who implements the event header?". We will look
> at what is available in the Fun4All framework as a starting point.
>
> If I got anything wrong, please comment to the list.
>
> Cheers
> Tony
>
>
>
>
>
> _______________________________________________
> sPHENIX-tracking-l mailing list
> sPHENIX-tracking-l AT lists.bnl.gov
> https://nam04.safelinks.protection.outlook.com/?url="https%3A%2F%2Flists.bnl.gov%2Fmailman%2Flistinfo%2Fsphenix-tracking-l&data=05%7C01%7Cjbertau%40purdue.edu%7Cd4d11a23d6dc4a0c7dc408db579a077c%7C4130bd397c53419cb1e58758d6d63f21%7C0%7C0%7C638200091309681420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=575gAegPIpxBYLXGflVRUBqS2jcc%2BWY10Xn6F3FXtTg%3D&reserved=0


--
Martin L. Purschke, Ph.D.        ;   purschke AT bnl.gov
                                  ;  
https://nam04.safelinks.protection.outlook.com/?url="http%3A%2F%2Fwww.phenix.bnl.gov%2F~purschke&data=05%7C01%7Cjbertau%40purdue.edu%7Cd4d11a23d6dc4a0c7dc408db579a077c%7C4130bd397c53419cb1e58758d6d63f21%7C0%7C0%7C638200091309681420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wpOi13tSiKnyy6EtoEyecfLfNAFVH5HAKuDOk7Bz7OE%3D&reserved=0
                                  ;
Brookhaven National Laboratory   ;   phone: +1-631-344-5244
Physics Department Bldg 510 C    ;   fax:   +1-631-344-3253
Upton, NY 11973-5000             ;   skype: mpurschke
-----------------------------------------------------------------------
_______________________________________________
sPHENIX-tracking-l mailing list
sPHENIX-tracking-l AT lists.bnl.gov
https://nam04.safelinks.protection.outlook.com/?url="https%3A%2F%2Flists.bnl.gov%2Fmailman%2Flistinfo%2Fsphenix-tracking-l&data=05%7C01%7Cjbertau%40purdue.edu%7Cd4d11a23d6dc4a0c7dc408db579a077c%7C4130bd397c53419cb1e58758d6d63f21%7C0%7C0%7C638200091309681420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=575gAegPIpxBYLXGflVRUBqS2jcc%2BWY10Xn6F3FXtTg%3D&reserved=0



Archive powered by MHonArc 2.6.24.

Top of Page