Bug #24821
Trigger bits assignment still incorrect
Description
Hi,
I'm a Mu2e user who recently tried to exploit the use of the new feature provided in art v3_06_02 that allows configuring the trigger_bits assigned to the trigger paths. It turns out that art is still re-arranging the order of the paths, and of the trigger_bits, in alphabetic order.
You can test verify this by running the following commands from one of the mu2egpvm nodes:
setup mu2e
cd /mu2e/app/users/gianipez/dev_Offline
source setup.sh
mu2e -c testAllTrig_ok.fcl -S sam_NoPrimary-mix_MDC2020d.txt -n 100
This file: /mu2e/app/users/gianipez/dev_Offline/gen/fcl/Trigger/offline/allTrig/allPaths_test.fcl shows the trigger bits assignment I set, but if you look the job summary (pasted also below), you can notice that the bits are assigned in a different way.
TrigReport ---------- Event Summary ------------
TrigReport Events total = 100 passed = 3 failed = 97
TrigReport ---------- Path Summary ------------
TrigReport Trig Bit# Run Passed Failed Error Name
TrigReport 1 0 100 0 100 0 caloCalibCosmic
TrigReport 1 1 100 1 99 0 caloMVACE
TrigReport 1 2 100 0 100 0 caloPhoton
TrigReport 1 3 100 0 100 0 cprCosmicSeedDeM
TrigReport 1 4 100 0 100 0 cprCosmicSeedDeP
TrigReport 1 5 100 0 100 0 cprLowPSeedDeM
TrigReport 1 6 100 0 100 0 cprLowPSeedDeP
TrigReport 1 7 100 0 100 0 cprSeedDeM
TrigReport 1 8 100 0 100 0 cprSeedDeP
TrigReport 1 9 100 0 100 0 largeCDCount
TrigReport 1 10 100 0 100 0 largeSDCount
TrigReport 1 11 100 0 100 0 minimumbiasCDCount
TrigReport 1 12 100 0 100 0 minimumbiasSDCount
TrigReport 1 13 100 1 99 0 tprCosmicSeedDeM
TrigReport 1 14 100 0 100 0 tprCosmicSeedDeP
TrigReport 1 15 100 0 100 0 tprHelixCalibIPADeM
TrigReport 1 16 100 1 99 0 tprHelixIPADeM
TrigReport 1 17 100 1 99 0 tprLowPSeedDeM
TrigReport 1 18 100 0 100 0 tprLowPSeedDeP
TrigReport 1 19 100 0 100 0 tprSeedDeM
TrigReport 1 20 100 0 100 0 tprSeedDeP
TrigReport 1 21 100 0 100 0 unbiased
Thanks for the help,
Gianantonio Pezzullo
History
#1 Updated by Kyle Knoepfel 5 months ago
- Estimated time set to 4.00 h
- Assignee set to Kyle Knoepfel
- Status changed from New to Assigned
- Category set to Infrastructure
- Subject changed from trigger_bits setting doesn't work to Trigger bits assignment still incorrect
- Project changed from cet-is to art
- Occurs In 3.06.02 added
Giani, I can reproduce the behavior. My sincere apologies for this--trigger bits are handled in multiple places, and it appears I missed one of them. I expect the fix to be straightforward, but it will require a new release of art.
#2 Updated by Kyle Knoepfel 5 months ago
- % Done changed from 0 to 100
- Status changed from Assigned to Feedback
This issue has been resolved with commit art:6b010b8. The one remaining question is whether you prefer an end-of-job summary that is alphabetical by path name (current):
TrigReport ---------- Path Summary ------------ TrigReport Trig Bit# Run Passed Failed Error Name TrigReport 1 1 1 0 1 0 a TrigReport 1 0 1 1 0 0 b
or by bit number:
TrigReport ---------- Path Summary ------------ TrigReport Trig Bit# Run Passed Failed Error Name TrigReport 1 0 1 1 0 0 b TrigReport 1 1 1 0 1 0 a
We will need to know what your preference is in terms of a release schedule. Is a release urgent, or can it wait for a week or two?
#3 Updated by Gianantonio Pezzullo 5 months ago
Hi Kyle,
No problem! I would prefer the paths to be listed by bit number (non alphabetically). I think it's not urgent, but I would like to make another question that might require also a small update/change in the code. trigger_bits is required to be dense, however, I except that during the run period we will change the list of the active trigger_paths, but at the same time it would be incredibly useful for the book-keeping to avoid changes in the trigger_bits assignment. So my question is, what is the supported way to do so?
Thanks for the help,
Giani
#4 Updated by Kyle Knoepfel 5 months ago
- Status changed from Feedback to Resolved
I will then make the trigger-bit summary ordered by bit number.
Regarding your question, the simplest approach would be to have placeholder paths with a single filter that returns true. The filter could be shared among many paths so that it is executed only once per event. For art to natively support sparse trigger bits, a significant design discussion and feature request would be required.
#5 Updated by Kyle Knoepfel 5 months ago
- Target version set to 3.06.03
#6 Updated by Kyle Knoepfel 4 months ago
- Status changed from Resolved to Closed