HltEfficiencyChecker needs candidates in every event even if the line failed - can cause failures
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.
MCDecayTreeTupletake 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_pvsfilter would be needed.