• Must be fully tested on a Linux system.
  (Inconsistencies in performance between Linux and other operating systems are sometimes observed.)
• Must work "out of the box".
  (Private modifications to code or RCP files, no matter how minor, are not acceptable.)
• Must run without crashing on samples of order 100K events:
  • On real data and Monte Carlo.
  • Single tool on its own and with all other released tools.
  • Memory leaks must be checked for.
• Particularly when new or modified tools and/or filters are being proposed, the filter code and the related trigger database entries must be tested, as well as that of the associated tools.
  
  • The performance must be measured in Trigsim, running a properly constituted trigger list including the proposed new triggers.
  • It is not enough to "simulate" this stage by applying private cuts on the objects produced by the tool.
  • Help with entering tool/filter/trigger definitions into the trigger database can be provided by the DØ triggermeisters or Terry Wyatt.
• Tool performance studies/plots: efficiency, rejection, etc. must be presented to the L3 algorithms group.
  (Interaction with and approval of the relevant ID group(s) obviously essential also.)
• Must test persistency of physics_results:
  • Write out events.
  • Read back in (without simulator being run) and check physics distributions OK.
• Up-to-date documentation of tool and filter algorithms and results on data and Monte Carlo must be provided.
  (We really mean it!).
• Once approved by the L3 algorithms group the performance studies must be presented to the DØ trigger board and receive approval before they are able to run online.

Verification:

• As soon as possible after the code is run online: run the simulator on data offline and check consistency with online results:
  • Event selection/trigger statistics.
  • Distributions from debug and physics results blocks.