Modernise PrintDecay

As an exercise of Gaudi::functional I transformed PrintDecay into a Consumer, see Phys!865 (merged).

All methods in PrintDecayTreeTool are made const. This requires the list of visited containers to be returned rather than an ugly common-block-like set be filled and cleaned.

Tests needed fixing in DaVinci, DaVinci!494 (merged)

mentioned in merge request Phys!865 (merged)

added 1 commit

• 5aff9d22 - Fixed formatting

Compare with previous version

added modernisation label

approved this merge request

• [2020-12-17 16:02] Validation started with lhcb-master-mr#1763

It seems useful to be able to print decay trees for debugging purposes in Moore which does not depend on Analysis. Why do you have to move the algorithm and tool?

Answering my own question, I guess because the interface was defined in Phys but the implementation in Analysis. Why not move the tool to Phys?

In fact I was going to be even a bit more pushy: why not move it straight to LHCb given that the tools seems rather generic? LbCom could probably do as well. This is very relevant having in mind that Phys is on the route towards obsolescence in run 3, hence making the removal to LHCb now would save work down the line. My 2 cents (apologies as this probably means a bit more work).

@sstahl There are other tools that also print decay trees. The LoKi::Hybrid::PrintTool is accessible in Moore. https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/davinci/latest/d9/d89/struct_i_print_decay.html . The PrintDecayTreeTool does Particles and MCParticles in a similar way.

Thanks, is there another functional algorithm accessible in Moore as well?

Not sure. We could also move the whole batch to Phys.

Seems a bit more logical to me, and Moore relies so heavily on algorithms being functional, that it might be useful to have it accessible in there.

I agree but I think @erodrigu has a good point that this could even move further upstream to LHCb or LbCom.

Lbcom's raison d'etre is to hold (simulation) stuff that's relevant for Boole and also reconstruction and analysis, but not Gauss. This tool is either useful for simulation output (it should go to LHCb) or not (it should go to Rec). Or you could take the view that it's closely related to event model, which also points to LHCb (could e.g. be used in simple tests).

IMHO Lbcom could eventually be retired, moving anything not needed in Boole to Rec, and anything needed in Boole to LHCb.

Right. So I would suggest we move things to LHCb as one may still want to print trees in MC (and if not, it does not harm to have the possibility).

marked as a Work In Progress

mentioned in merge request DaVinci!494 (merged)

I had a look. PrintDecayTreeTool needs DaVinciMCKernel, which is in Phys. There's no well-suited package in Phys that includes DaVinciMCKernel. One solution would be to move the whole of DaVinciMCTools to Phys https://gitlab.cern.ch/lhcb/Analysis/-/tree/master/Phys/DaVinciMCTools. We can then later decide what is needed in Moore and needs to go to Rec and what can go back to Analysis, but that will likely mean splitting packages.

Opinions, @sstahl @cattanem @gligorov ?

are the interfaces really needed? I.e. can you get rid of the tool and only have an algorithm?

Indeed. That would make complete sense if the interface is there for a single tool (later for a single algorithmor not). To avoid trouble you could get rid of the interface in a second, following step, after the removal of everything to LHCb.

That can be done. But we still need a host package for the merged PrintDecayTree+PrintDecayTreeTool, that now depends on simulation.

Unless I make a simulation-agnostic algorithm.

Ah, I most probably don't have the full overview of all dependencies and relevant includes. Fair enough. As a host package you could even put everything in a new Phys/Tools package? I guess that anyway a lot will be reorganised as part of modernisations and clean-ups, so why not try and have less sub-packages per project? (I hope that's not a pain, otherwise ignore.)

I will not start a new development on the last day before Christmas . I made an issue #8 (closed) . Please discuss there.

More than reasonable :-)!

added 1 commit

• 1d8f0bcc - formatting

Compare with previous version

Moved PrintDecayTree back to Phys

added 1 commit

• db4d8df3 - Fixed formatting

Compare with previous version

changed the description

unmarked as a Work In Progress

mentioned in issue #8 (closed)

• [2020-12-18 15:58] Validation started with lhcb-master-mr#1765
• [2020-12-20 00:16] Validation started with lhcb-head#2828

mentioned in issue Moore#237 (closed)

added lhcb-head label

merged