Skip to content

HltEfficiencyChecker needs candidates in every event even if the line failed - can cause failures

For HLT2, MCDecayTreeTuple has a datahandle-based dependency on the reconstructed candidates from each line running in each event, so that it can compare the reconstructed hits to the truth hits for TrueSim matching. At runtime, the matching is smart enough to know to not try to match if the trigger line failed on that event. However, the data dependency means that the scheduler schedules the building of the candidate in every event regardless. So you can rarely run into issues where the candidate cannot be built and there is a failure, e.g. like

Hlt2RD_KS0ToPiE_Loose_Combiner        ERROR Sel::calculateBestVertex : Empty vertex container passed to Sel::calculateBestVertex()
Hlt2RD_KS0ToPiE_Loose_Combiner        ERROR Maximum number of errors ( 'ErrorMax':1) reached.
HLTControlFlowMgr                     FATAL Event failed in Node MCDecayTreeTuple/MCDecayTreeTuple : Error in algorithm execute
HLTControlFlowMgr                     FATAL *** Event 372 on slot 0 failed! ***
HLTControlFlowMgr                      INFO Dumping Alg Exec State for slot 0:

as observed recently. In the trigger line's control flow, it would stop before this point, because it has some filter like require_pvs that stops it getting this far, but such a filter is not part of the candidate-building, and so it is not run here.

Ideas

  • Can MCDecayTreeTuple take the output directly from the line, which should be e.g. an empty container when the line didn't fire?
  • Can the combiners/candidate builders know the dependencies they have? If they knew they needed PVs, they could hopefully just return an empty container and stop, and no up-front require_pvs filter would be needed.