sPHENIX is a new detector at RHIC.

[Martin Purschke <purschke AT bnl.gov>]

Dear all,

as we started discussing cabling plans and channel mappings for
detectors (we are about to put out an ICD for DAQ-OHCal), let me
explain, especially to people new to sPHENIX, how that mapping works in
general. This is largely how we did things in PHENIX, and it has served
us very well over many years.

Each detector adds a number of "packets" to the data stream. You can
think of such a packet as covering a certain area of real estate on a
given detector system, such as a part of a sector of the EmCal, or a
certain group of tiles on the OHCal. Likewise, a piece of a phi-sector
of the TPC, and so on. Like the pieces of a puzzle, the packets'
individual coverage areas then make up the entire detector.

Which channels feed their data into such a packet must never change, and
each packet has a unique packet id, which also stays the same.

In this way, channel x in packet y uniquely identifies a given channel
in sPHENIX. By extension, a packet typically identifies a piece of
readout hardware. In PHENIX we soon started to refer to FEMs by their
packet id ("we had a problem with 4232 last night").

The packet IDs are assigned by "detector number". Starting from what is
now the MBD, we go from the inside out, for example

1 - MBD
2 - MVTX
3 - INTT
4 - TPC
5 - reserved
6 - Emcal
7 - IHCal
8 - OHCal

14 - trigger (that's what we are used to)

Packet ID's for a given detector will then be assigned as

1000 * detector number + 1,2,3,4...

so the OHCal would start with 8001, 8002, and use as many packets as
needed in its range. Each detector is largely free to assign the IDs in
that range, within reason. For example, the EmCal could go for
contiguous numbers, or assign sub-ranges for north and south - we'll see
what's best.

The "even 1000" numbers (like 8000 for the OHCal) are reserved for a
future meta-packet in case we have to change a subsystem's packet
composition after all. Then we would add that packet to specify (or
maybe just indicate) a new mapping. In PHENIX we never had to exercise
that option.

All that serves to decouple the reconstruction software from changes in
the DAQ landscape. Once you have established a channel mapping for your
detector in the reco software, this should be good through the lifetime
of sPHENIX.

The packets and their interfaces also shield the offline software from
routine changes in the DAQ. The data encoding for virtually all
detectors will change over time as we gain experience and confidence to
more efficiently package the data. Still, you ask for the "value of
channel x of packet y" and get the answer through a set of standard
APIs, so the reco software will be oblivious to such changes.

We will maintain the packet id ranges and the internal mappings in the
ICD documents.

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
-----------------------------------------------------------------------