sPHENIX MAPS tracker discussion

[Martin Purschke <purschke AT bnl.gov>]

Hello MVTXers,

it has become clear that with my current workload I have been able to 
devote maybe just 30 minutes a week to the ongoing decoder development. 
I understood from today's SCM that you want to pull this effort back and 
finish it.

I'm sure I have not seen every possible variation in the format, but I 
think that this is in a state that a few more hours of work can get it 
finished.

I have committed what I have at this point to my development clone in

https://github.com/mpurschke/online_distribution


in the master branch. It obviously compiles, but more importantly it 
does not depend on any external libraries, and also decodes the chip 
data correctly. There were a few quirks and question marks if I 
recognize all the different cases correctly... oh well.

I you enable the commented-out lines 320..322, you match most of the 
output of the python decoder -

> ddump -p 2001  test_00000107-0000.prdf | more
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2
> FELIX header found: Version 1 FLXID 0 GBT_ID 3
> FELIX header found: Version 1 FLXID 0 GBT_ID 1
> FELIX header found: Version 1 FLXID 0 GBT_ID 2


(as per Jo's suggestion from a while ago, that test_00000107-0000.prdf 
is the golden development data file b/c of its known properties. )

In general there are tons of commented-out debug output lines so you can 
get an easy trace of the structures.

Completely analogous to the TPC and INTT APIs, the decoder populates a 
long list of "mvtx hits" - you ask the packet how many of those there 
are, go through them one by one, and so populate the map of pixels fired.

> $ ddump -p 2001  test_00000107-0000.prdf | more
> Number of hits: 33327
>  hit number   addr   enc.id   lane   src.id      BCO         LHC BC
>      0        510       0       0      32      0x21240422      0x0
>      1        511       0       0      32      0x21240422      0x0
>      2        512       0       0      32      0x21240422      0x0
>      3        513       0       0      32      0x21240422      0x0
>      4        514       0       0      32      0x21240422      0x0
>      5        515       0       0      32      0x21240422      0x0
>      6        516       0       0      32      0x21240422      0x0
>      7        517       0       0      32      0x21240422      0x0
>      8        510       0       0      32      0x21240422      0x0
>      9        511       0       0      32      0x21240422      0x0
>     10        512       0       0      32      0x21240422      0x0
>     11        513       0       0      32      0x21240422      0x0
>     12        514       0       0      32      0x21240422      0x0
>     13        515       0       0      32      0x21240422      0x0
...

The way to access the APIs is shown in the packet's dump(...) function 
that per policy uses the API calls, lines 566... 581.

Jakub pointed out that there are more memory-efficient ways to store the 
hits, and that's of course true. I don't think we care about the memory 
footprint at this point, which is still minuscule compared to other 
parts of the reconstruction.

I hope I could contribute significantly to the effort, and of course I'm 
still around.

Best,
        Martin


--
Martin L. Purschke, Ph.D.        ;   purschke AT bnl.gov
                                 ;   http://www.phenix.bnl.gov/~purschke
                                 ;
Brookhaven National Laboratory   ;   phone: +1-631-344-5244
Physics Department Bldg 510 C    ;   fax:   +1-631-344-3253
Upton, NY 11973-5000             ;   skype: mpurschke
-----------------------------------------------------------------------