Level 2 and the Triggermeister in Run I

The Trigger List and Operating Level 2

• small parameter sets and numbers of tools
• aimed at very specific physics or object-ID goals
• we imagined using the multiple output streams to pre-stream to physics groups

• we reserved (good thing) a L1 bit for testing purposes
• we started bandwidth allocation, but without evaluating overlaps

• it was difficult to assign filters to specific physics groups
• the filter bit names were more stable than their bit numbers or contents
  • bit numbers of L2 bits under a L1 not contiguous (COOR peculiarity)
  • bit numbers change because of changes elsewhere in the list, or in test runs
  • bit numbers did not change when their meaning changed
    • how many bits would be needed to reflect every change?
  • bit names did not change when their meaning changed
    • JTL: a tradeoff between ease of streaming and forcible recognition of boundaries in a data set
  • JTL: user view by name worked after TSUM bank installed, but need for numbers remains for purposes of ordering and hand-scanning of trigger lists
  • JTL: better procedures needed:
    • not all trigger changes (especially bugs) were marked by a version number
    • trigger releases failed on download: COOR_SIM not used
    • hardware changes in .CTL file not uniformly tracked
    • The trigger version was never stamped on the data
  By the middle of Run 1A, things started to change
  • filter bits "owned" much more by physics groups than by filter developers
  • filter conditions became more complex
  • TRIGPARSE helped us quite a bit but
    • proofreading is still important
    • proofreading often was sometimes skipped
    • TRIGPARSE should be extended to provide the "summary" information, which is all that many users ever look at: it must conform to what is being run online
    • though TRIGPARSE hid the default values, tools may had too many parameters
  • runs were found where the actual bit assignments did not conform to the advertised values in the standard trigger lists (The TSUM banks are always right)

  Special Runs

  • Assume triggers can saturate the available bandwidth
    • might be a good area for dynamic prescaling to enforce this
  • Handy, because data is naturally concentrated
  • The level 2 rates were seldom known until the new code is run with beam, as they are usually background-dominated.

  Online Testing of L2 Code

  • Setting up a test of a new version is difficult
  • Many factors need to be coordinated and enter into decisions
  • New L2 code will cause loss of beamtime (even with SHADOW testing)
  • But the new code also improves operating efficiency