Modernize MCDecayTreeTuple, TupleToolTrigger and TupleToolEventInfo

FYI @rmatev @sstahl @mvesteri

For the HltEfficiencyChecker tool (prints out/plots some efficiencies for the new HLT, see https://gitlab.cern.ch/lhcb/mooreanalysis/merge_requests/1) I use some tuple tools to write trigger decisions and basic kinematic information to a tuple. To make these work with the new scheduler so they can be added to the control flow following Moore, some modernisation/addition is needed:

• TupleToolTrigger and TupleToolEventInfo now use data handles to declare their data dependencies. Drop L0 code. They also look for trigger dec reports with strings ending in Line rather than Decision, as they are written these days.
• MCTupleToolKinematic also adds the eta variable to tuples - this is useful so you can ask for an efficiency if all the children of a decay fall within the eta acceptance of LHCb.
• MCDecayTreeTuple declares its tools in the initialise method, so their data dependencies are made explicit. Beforehand tools were only instantiated when they are first asked for. This code is pretty much copied from the initializeStufferTools method of Phys/DecayTreeTupleBase/DecayTreeTupleBase/DecayTreeTupleBaseTemplates.icpp and could possibly be improved.

TODO:

• The fact that the dec reports have the Line suffix rather than the Decision as in Run 2 probably shouldn't happen, and so perhaps this should instead be fixed in Moore, rather than changing what the tuple tool looks for here.
• Fix formatting?
• Update the treatment of HLT2 as well as HLT1 in TupleToolTrigger, and remove L0? POSTPONE HLT2 TO EXTENSION OF TOOL TO HLT2
• Improve the initialisation of the tools in MCDecayTreeTuple?

A dependency of https://gitlab.cern.ch/lhcb/mooreanalysis/merge_requests/1. Depends on LHCb!2319 (merged), LHCb!2373 (merged), Phys!662 (merged)

added 3 commits

• 61760237...0a61dd9e - 2 commits from branch master
• df05a432 - Merge branch 'master' into tuple-tool-data-handles

Compare with previous version

added 1 commit

• 8f43c963 - Return formatting to previous state

Compare with previous version

added 1 commit

• 260a6b01 - More format fixing

Compare with previous version

changed the description

marked the checklist item Fix formatting? as completed

I tried to remove any reference to L0 in TupleToolTrigger, but a lot of related members come from the TupleToolTriggerBase class, and then tools like TupleTollTISTOS and TupleToolStripping depend on this base class. Updating all these tools makes this MR bigger and gets away from the purpose of this MR, which is to make https://gitlab.cern.ch/lhcb/mooreanalysis/merge_requests/1 work.

I also briefly tried to treat Hlt2 the same as Hlt1, but for this to work one has to tell the tuple tools where the Hlt2DecReports are. In the case of Hlt1, we do this in the script hlt1_runtrigger_maketuple.py, which configures the algorithms and control flow of HltEfficiencyChecker - so to do the same for Hlt2 starts to amount to extending the tool in general to handle Hlt2. This is a bigger job that is one of the natural next steps.

I think it should be dedicated follow-up issues/MRs that tick the box above. Do people agree @rmatev @sstahl @mvesteri?

mentioned in issue Moore#130 (closed)

added 1 commit

• 0c5756aa - Happy with the initialisation in MCDecayTreeTuple

Compare with previous version

marked the checklist item Improve the initialisation of the tools in MCDecayTreeTuple? as completed

added 1 commit

• 028281cf - Removed reference to L0 in TupleToolEventInfo - this kills warnings

Compare with previous version

added 1 commit

• 41070f44 - Removed reference to L0 in the header

Compare with previous version

marked the checklist item Update the treatment of HLT2 as well as HLT1 in TupleToolTrigger, and remove L0? as completed

changed the description

added 1 commit

• aef4d67c - Revert from "Line" to "Decision"

Compare with previous version

As discussed in Moore#130 (comment 3150092), the plan is to revert "Line" back to "Decision", thus I have reverted this change to TupleToolTriggerBase.h.

I am now happy with this MR, but it will have dependencies on upcoming MRs from @rmatev in both LHCb and Phys. I will mark them as dependencies for this MR when those MRs appear.

resolved all threads

marked the checklist item The fact that the dec reports have the Line suffix rather than the Decision as in Run 2 probably shouldn't happen, and so perhaps this should instead be fixed in Moore, rather than changing what the tuple tool looks for here. as completed

changed the description

changed the description

changed the description

unmarked as a Work In Progress

• [2020-02-06 00:09] Validation started with lhcb-gaudi-head#2524
• [2020-02-06 00:22] Validation started with lhcb-gaudi-head#2524
• [2020-02-06 00:41] Validation started with lhcb-gaudi-head#2524
• [2020-02-07 00:12] Validation started with lhcb-gaudi-head#2525
• [2020-02-08 00:12] Validation started with lhcb-gaudi-head#2526
• [2020-02-09 00:09] Validation started with lhcb-gaudi-head#2527
• [2020-02-11 00:13] Validation started with lhcb-gaudi-head#2528

mentioned in merge request LHCb!2319 (merged)

The builds and tests for this seemed fine last night: https://lhcb-nightlies.web.cern.ch/nightly/summary/#day2slot_lhcb-master-mr_447. I think this is ready to merge.

assigned to @rmatev

unassigned @rjhunter

added Tuples modernisation labels

changed the description

changed title from Some Modernization of MCDecayTreeTuple, TupleToolTrigger and TupleToolEventInfo to Modernize MCDecayTreeTuple, TupleToolTrigger and TupleToolEventInfo

changed the description

added 1 commit

• becb1912 - Apply suggestion to Phys/DecayTreeTupleMC/src/MCTupleToolKinematic.cpp

Compare with previous version

added 3 commits

• 6ee5a342 - Just call initializeStufferTools rather than duplicate its code
• 0079d993 - Make some tool lists private again
• a8787bf6 - Merge branch 'tuple-tool-data-handles' of...

Compare with previous version

added 1 commit

• 4170d6d3 - Forgot one tool to make private

Compare with previous version

• [2020-02-12 00:09] Validation started with lhcb-gaudi-head#2529
• [2020-02-13 00:09] Validation started with lhcb-gaudi-head#2530

The nightlies seemed happy with this, the only error in Analysis was a timeout in clang-dbg and do0 that I assume to be unrelated. There is a new error in DaVinci (https://lhcb-nightlies.web.cern.ch/logs/tests/nightly/lhcb-gaudi-head/2529/x86_64-centos7-clang8-dbg/DaVinci/) and in Bender (https://lhcb-nightlies.web.cern.ch/logs/tests/nightly/lhcb-gaudi-head/2529/x86_64-centos7-gcc9-opt/Bender/) but I can't see how this relates?

resolved all threads

approved this merge request

FYI @rangel @amato this solves the same or similar problems you were having when running (MC)DecayTreeTuple in Moore.

unassigned @rmatev

merged

mentioned in commit 138f8d14