Setting of Detector SourceID in Subdetector Encoding

changed the description

@adavis Please remove the post above. I gave you the wrong information. I also made the same mistake. I asked in the dataflow meeting. The correct definition is here: https://edms.cern.ch/ui/#!master/navigator/document?D:100324657:100324657:subDocs

This means I also have to adapt the MEP encoding accordingly. It also means that only MEPs can be encoded, which have the correct source ID, because there deducing the detector id from the bank type is ambiguous.

No worries and done!

Looking at the EDMS document, the top5 bits of the source ID should map to the bit used for the partition in the table. Some subdetectors have 2 bits, one for A-side and one for C-side.

It is therefore indeed ambiguous to deduce the top5 bits from the bank type alone. I see three options that could be used until all encoders have been fixed to properly set the sourceID:

In principle the detector geometry can be used to find if a source ID is either A or C side. For example for the Velo (unchecked if right/left really corresponds to A/C side) :

const DeVP& vp = ...;
const auto sensor = LHCb::VPChannelID::SensorID( raw_bank->sourceID() );
auto a_side = vp.sensor( sensor ).isRight();

The A-side is set for all subdetectors, and the top5 bits are ignored in the decoders. This will work for Allen as it doesn't distinguish between A and C sides.
Reintroduce a mode to Allen where the bank type can be used to map MFPs to subdetectors

Not 2 bits, two numbers. 5 bits are enough to store the 32 TFC partitions defined in LHCb. UT, VELO and SciFi each have two numbers for side A and C

Indeed, apologies for the confusion. The table Markus mentioned contains bit, but as far as I can see the number of the bits in the table is used as a number in the sourceID.

I think A-side is left, no?

cc: @gcavalle, @edelucia

From the RICH side: !382 (merged)

From SciFi: LHCb!2942 (merged) @raaij @lohenry please update if incorrect

First version with header implemented in Detector!169 (merged) . File is https://gitlab.cern.ch/lhcb/Detector/-/blob/lohenry-ft-decoding-v7/Detector/FT/include/Detector/FT/FTSourceID.h and the only important line is 71. Does that correspond to what you want? I will then have to edit the SIMCOND to match the new sorting (A side, then C side).

@frankm @rmatev can you please confirm? IIUC, this is correct.

More follow up: Detector!186 (merged)

@frankm @graven I am a bit confused here, our note mentions this:

It seems we disagree if the ID has 32 or 16 bits, is it that? In the EDMS note I see that bits 16-31 are not used yet.

Not sure to which EDMS note you are referring. The definition is in https://edms.cern.ch/document/2100937 Table 5 (and Table 3) define SRCID to be 16 bit

Then implementation before !186 (merged) was correct, no? @graven

OK, my mistake -- I though it had 32 bits (and not 16). Corrected the mistake in Detector!186 (merged)

(would be nice in that case if the FTSourceID would use an unsigned 16 bit type internally instead of using unsigned int -- which is probably the source of my confusion -- so now fixed that as well in Detector!186 (merged): the masks are now enforced by the compiler to explicitly fit in 16 bits)

From the Muon: LHCb!3133 (merged) which includes !377 (merged) . The update to the source ID is to be added. @satta Please correct this info if incorrect

Detector!173 (merged) to also be included in this list

SourceID for muon is now in GIT. It is part of LHCb!3133 (merged) merge request code

a small follow up for muon was needed: LHCb!3764 (merged)

Looks ok to me: 0b00111 = 7 and 0b01000 = 8 as stated in https://edms.cern.ch/ui/file/2100937/5/edms_2100937_raw_data_format_run3.pdf page 4 and the shift is 11 bits (FTSourceID::totalBits):

>>> '%04X'%(0b00111<<11)
'3800'
>>> '%04X'%(0b01000<<11)
'4000'
``
In the banks the source id is uint16_t which should fit.

Setting of Detector SourceID in Subdetector Encoding

Designs

Child items ...

Activity