sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion
- 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
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
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
-
[Sphenix-tracking-l] Subsystem readout to reconstruction discussion,
Anthony Frawley, 05/17/2023
-
Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion,
Martin Purschke, 05/18/2023
-
Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion,
Bertaux, Joseph Tyler, 05/18/2023
- Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion, Anthony Frawley, 05/18/2023
-
Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion,
Bertaux, Joseph Tyler, 05/18/2023
- <Possible follow-up(s)>
-
Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion,
Ming Liu, 05/17/2023
- Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion, pinkenburg, 05/18/2023
-
Re: [Sphenix-tracking-l] Subsystem readout to reconstruction discussion,
Martin Purschke, 05/18/2023
Archive powered by MHonArc 2.6.24.