Addition of a line algorithm for PLUME activity

Related

Key component of #437 (closed)

Description

This MR creates a new line algorithm for selecting events based on PLUME activity. The new algorithm is named plume_activity_line_t.

The implementation counts the number of PLUME ADC counts in an event that are at least as large as a configurable threshold. If the number of PLUME ADCs over that threshold is great or equal to a configurable minimum, then the event is accepted.

A new maker for lines of this type is added to hlt1_monitoring_lines.py. An instance of the new line type is added to the set of lines returned by HLT1.default_bgi_activity_lines().

Implementation of plume_activity_line_t

This implementation of plume_activity_line_t is an EventLine.

Inputs

In addition to the standard input required for an EventLine, plume_activity_line_t requires the following device input:

• dev_plume_t: the decoded PLUME data

Properties

In addition to the standard properties provided by an EventLine, plume_activity_line_t has the following configurable properties:

• plume_channel_mask: type uint64_t: a bitset that defines which of the 64 PLUME FEB channels will be used/allowed in the trigger decision. Defaults to 0x003FFFFF003FFFFF (channels [0, 21] and [32, 53]).
• min_plume_adc: type unsigned: the threshold for ADC counts. In order to contribute to a positive trigger decision, a PLUME channel must have an ADC count >= min_plume_adc.
• min_number_plume_adcs_over_min: type unsigned: the threshold for the number of used/allowed channels with ADC counts over threshold. An event is accepted if the number of channels that are allowed by plume_channel_mask and that have ADC counts >= min_plume_adc is >= min_number_plume_adcs_over_min

How it works

plume_activity_line_t implements the following required class methods:

• plume_activity_line_t::get_input()
• plume_activity_line_t::select()

plume_activity_line_t::get_input() analyzes the PLUME ADC counts and returns a 64-bit bitset that indicates which of the channels have ADC counts >= min_plume_adc.

plume_activity_line_t::select() performs a bitwise & of the plume_channel_mask and the over-threshold-bitset returned by plume_activity_line_t::get_input() to get a bitset of used/allowed channels that are over threshold. It counts the number of set bits with a while loop that should emulate a popcount. The decision returned by select() is true iff this number is >= min_number_plume_adcs_over_min.

added Luminosity Plume new feature selection labels

@balagura @edallocc @elniel @fferrari I have a first draft of an implementation here. Is it the kind of selection that is needed?

added RTA label

added 1 commit

• d1e4c86c - Minor code improvements; trying to be less archaic.

Compare with previous version

assigned to @spradlin

added 17 commits

• 9b31153a...b00fe4d3 - 15 commits from branch master
• 6bd010d5 - First draft of a line algorithm that select events based on PLUME activity
• 846a5bcb - In main configuration file HLT1.py, added prefilter to PLUME activity line. ...

Compare with previous version

@balagura @edallocc @elniel @fferrari Has someone independently tested this new PLUME activity line algorithm? The testing that i have done is very crude---i have verified that it can accept and reject events depending on the values of its configuration properties.

What i would like to see are the results of someone running the line over a sample of several events for which the PLUME data is independently known. I would like to see the results for several configurations of the line that demonstrate that it selects and rejects the events that one would expect based on the thresholds and the independently known PLUME data.

resolved all threads

@elniel @fferrari i have a couple of final implementation questions,

1. Note that the ADC threshold is applied as > while the number of channels threshold is applied as >=. This made sense to me at the time, but would you prefer the thresholds to be applied with the same comparison operator?
2. @fferrari's comment in a previous thread notes that only a subset of the channels have meaningful data. Do you want to be able to configure a mask for the valid channels that 'count'?

Ho @spradlin,

Just my two cents. Regarding 1) I don't care as long as the used channels are the right ones. Regarding 2), I don't know. Are you using all the channels or just the ones that I told you? What would be the use of that mask? To possibile change the used channels in the future? I think we will always use the whole detector to count and even if one PMT will break down it should not affect the counting (here by whole detector I mean channels 0-21 and 32-53). Anyway, if that it's easy to implement I don't see any reason against that. Let'see what others think maybe?

Cheers and thanks a lot for all this very fast work,

Fabio

@fferrari The line algorithm currently looks at all 64 of the channels and counts the number that are over threshold. The idea of the mask would be to make the line decision on just a configurable subset of the channels, like just the 44 valid channels.

Hi @spradlin , now I got it, thanks. So, on a practical point of view it does not change anything to loop over 64 or 44 channels, since all the disconnected channels (22) have values around 256 and since the threshold will be higher than that, they should not bias anything in the computation.

However, for the sake of clarity and readability I think that the mask is a good a idea. I support that.

Cheers,

Fabio

added 10 commits

• 846a5bcb...d0b7d0b4 - 7 commits from branch master
• 3fdba0f6 - First draft of a line algorithm that select events based on PLUME activity
• b639ec4d - In main configuration file HLT1.py, added prefilter to PLUME activity line. ...
• 6fa835ad - Added to PlumeActivityLine algorithm a property to define a PLUME channel...

Compare with previous version

added 1 commit

• a47e10a0 - In PlumeActivityLine, made comparison operators consistent for the ADC test...

Compare with previous version

changed the description

changed the description

/ci-test

added ci-test-triggered label

• [2023-06-15 11:19] Validation started with lhcb-master-mr#8254

marked this merge request as ready

unassigned @spradlin

assigned to @yagao

mentioned in issue #437 (closed)

resolved all threads

changed milestone to %RTA/2023.07.04

assigned to @rmatev

unassigned @yagao

added 27 commits

• a47e10a0...6bb3484a - 21 commits from branch master
• 09c11d59 - First draft of a line algorithm that select events based on PLUME activity
• cd4078bd - In main configuration file HLT1.py, added prefilter to PLUME activity line. ...
• 350e98c2 - Added to PlumeActivityLine algorithm a property to define a PLUME channel...
• f04f2497 - In PlumeActivityLine, made comparison operators consistent for the ADC test...
• ab189704 - Disable UT in hlt1_pp_vdm_bgi
• 331d8c3f - Sensible defaults for cluster activity BGI line

Compare with previous version

@spradlin FYI I've rebased and pushed a couple of extra commits to put some sensible defaults and disable the UT.

changed milestone to %RTA/2023.06.1

merged

mentioned in commit 79fa6d2d

mentioned in issue Moore#598 (closed)