Project

General

Profile

Bug #24821

Trigger bits assignment still incorrect

Added by Gianantonio Pezzullo 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Kyle Knoepfel
Category:
Infrastructure
Target version:
3.06.03
Start date:
08/19/2020
Due date:
% Done:

100%

Estimated time:
4.00 h
Spent time:
4.00 h
Occurs In:
3.06.02
Scope:
Internal
Experiment:
Mu2e
SSI Package:
Duration:

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 2 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 2 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 2 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 2 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 2 months ago

  • Target version set to 3.06.03

#6 Updated by Kyle Knoepfel about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF