Add modules to produce a boolean value, and filter based on it

[fwyzard]

PR description:

Add two modules:

• BooleanProducer reads a boolean value from the configuration, and "produces" it into the event;
• BooleanFilter reads a boolean value from the event, and accepts or rejects the event based on it.

Together with a SwitchProducer, these modules allow recording in the events' TriggerResults which of the branches was taken.

PR validation:

None.

if this PR is a backport please specify the original PR and why you need to backport that PR:

Backport #31221 for use in the next MWGR.

[fwyzard]

backport #31221

[fwyzard]

@cmsbuild, please test

[cmsbuild]

The tests are being triggered in jenkins.

• CMSSW_11_1_X_2020-08-24-1100/slc7_amd64_gcc820: https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/8896/console Started: 2020/08/24 23:41

[cmsbuild]

A new Pull Request was created by @fwyzard (Andrea Bocci) for CMSSW_11_1_X.

It involves the following packages:

FWCore/Modules

@makortel, @smuzaffar, @cmsbuild, @Dr15Jones can you please review it and eventually sign? Thanks.
@makortel, @wddgit this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

• Backported from Add modules to produce a boolean value, and filter based on it #31221

[cmsbuild]

+1
Tested at: 7c915fa
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-3741f8/8896/summary.html
CMSSW: CMSSW_11_1_X_2020-08-24-1100
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-3741f8/8896/summary.html

@slava77 comparisons for the following workflows were not done due to missing matrix map:

• /data/cmsbld/jenkins/workspace/compare-root-files-short-matrix/data/PR-3741f8/23234.1001_TTbar_14TeV+RecoFullGlobal_TestOldDigi_2026D49+HARVESTFullGlobal_2026D49

Comparison Summary:

• No significant changes to the logs found
• Reco comparison results: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 36
• DQMHistoTests: Total histograms compared: 2780792
• DQMHistoTests: Total failures: 1
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2780741
• DQMHistoTests: Total skipped: 50
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 35 files compared)
• Checked 152 log files, 16 edm output root files, 36 DQM output files

[makortel]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_11_1_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_11_2_X is complete. This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[makortel]

Together with a SwitchProducer, these modules allow recording in the events' TriggerResults which of the branches was taken.

Do I assume correctly that the purpose is to monitor the SwitchProducer choices via TriggerResults?

Is that specific for the MWGR, or do you think it would be useful also in longer term?

If for longer term, maybe we could think about a more automated way to record the choices. (in principle the information is in the event provenance, but crafting a generic monitoring for the choices from the provenance would not be straightforward)

[qliphy]

+1

[fwyzard]

Do I assume correctly that the purpose is to monitor the SwitchProducer choices via TriggerResults?

Correct.

Is that specific for the MWGR, or do you think it would be useful also in longer term?

I think it's something we will want in the long term, at least at HLT:

• if we equip only part of the farm with GPUs, to keep track of the events processed on GPU vs CPU
• if we equip the whole farm with GPUs, to monitor that there is no unexpected fallback to CPUs

Using an entry in the TriggerResults has at least a few nice properties:

• it can be monitored with the existing online tools like OMS
• it can easily be checked in the event data, in the online DQM, offline analyses, etc.

If for longer term, maybe we could think about a more automated way to record the choices. (in principle the information is in the event provenance, but crafting a generic monitoring for the choices from the provenance would not be straightforward)

Of course I don't mind a more automated way - as long as it is just as easy to use :-)