search

cmsdaq / DAQExpert

New expert system processing data model produced by DAQAggregator
1 stars 2 forks source link

add support for defining threshold for 'no trigger rate' #171

Closed andreh12 closed 6 years ago

andreh12 commented 6 years ago

When data taking and trigger is configured to record splashes (like now), there are typically extended periods with no triggers at all (even the calibration sequence is turned off) to make sure the splashes are (almost) the only triggers which fire, the shift crew can immediately check the event display and splashes are not lost due to inhibiting triggers during the calibration sequence.

However, this leads to a somewhat annoying rate of sound alerts about 'no rate when expected' in the control room :-)

As discussed with @dinyar on the phone, a simple solution for this case would be to introduce an easily configurable parameter defining what should be considered 'zero' in the class NoRate. This parameter could temporarily be set to minus one during splash data taking.

As a bonus, the DAQExpert could have a special 'splashes' mode which would generate a sound every time the number of triggers increases by a (configurable) number between snapshots (see also https://github.com/cmsdaq/DAQExpert/issues/29#issuecomment-271580418 and #50) but that should be a discussed in a separate issue.

andreh12 commented 6 years ago

a run with splashes is run 313133, see e.g. http://daq-expert.cms/DAQExpert/?start=2018-03-30T07:59:40.560Z&end=2018-03-30T10:00:44.813Z

andreh12 commented 6 years ago

I produced a hotfix release based on 2.9.16 which is currently in production with pull request #172 : https://github.com/cmsdaq/DAQExpert/releases/tag/2.9.16-splashes

andreh12 commented 6 years ago

About the automatic detection of 'splashes' mode: the level Zero function manager publishes the value of L1_HLT_TRIGGER_MODE in the levelZeroFM_dynamic flashlist (outside of running state it is however N/A). During data taking for LHC beam splashes, this key typically contains the word splashes (at the time of writing, there are at least two keys containing the word splashes).

So a proposal for detecting splashes mode (which would then allow to make splash-specific conclusions in the logic modules) would be to introduce a configurable parameter corresponding to a regular expression (e.g. .*splashes.*) which would be matched against the value of L1_HLT_TRIGGER_MODE of the toppro instance.

However, since it is unlikely that we will get splashes before LHC Run 3 (apart from those in the coming few days), there is no urgency to implement this now.

andreh12 commented 6 years ago

The corresponding code changes were deployed as a hotfix and merged back to master and dev (see also #171).