Move Phys/Particle2MCTruth to Rec?

I see that at least the algorithm MCMatchObjP2MCRelator in package Phys/Particle2MCTruth is needed upstream in the stack in Rec by Phys/MCAssociation/src/MCTruthAndBkgCatAlg.cpp. It hence seems Phys/Particle2MCTruth should be moved to Rec. And if the tool is only needed by one algorithm then the simplest may be to move the tools to Phys/MCAssociatio, avoiding a spurious extra package.

I'm assigning to you @amathad and @pkoppenb but that's more for the relevance to stuff used in connection with FunTuple for MC matching. What do you think?

added cleanup label

assigned to @pkoppenb and @amathad

changed the description

For maintenance purposes, the move is fine by me.

However, I am also thinking if some of these association tools and algorithm can be retired in favour of tools for building relation table and functor composition that have become available since they were first written. But this is different issue altogether.

I'm pretty convinced as well that some bits can be retired. But I know the pain it has been the clean-up (which will be a win in the medium and longer term). It is clear that the tools and algorithms remaining will all have to be modernised. This is the only way to, eventually, have a multi-threaded DaVinci application, a goal I always mentioned.

In short, we both agree on all points but this move is a first step, pragmatically given all that is going on :-).

BTW, it is not only about maintenance. One should not conceptually be using in a Rec algo a tool that is downstream in Analysis ;-). The fact that it's been working is of course because the algorithm is used in DaVinci jobs that link to both projects.

Indeed, the MCTruthAndBkgCatAlg moved around quite bit: was in Analysis, then moved to Phys and then Phys got retired and moved to Rec, so somewhere here this dependency tracking got lost.

On a different note but related to this point @erodrigu there are currently some open MRs (!898 (merged)) that import in functorcollections classes defined in DV (e.g. here) for printing the collections. I am wondering if the right place for functorcollections is in DV and not Analysis`. WDYT? (We can discuss this in that relevant MR, just thought I should bring this up here first).

I'm not sure it's conceptually wrong to use an Analysis tool from a Rec algorithm. Historically our software has been designed such that interfaces live in LHCb (no longer true) and tools stay where they are needed. So presently one could call FunTuple from Moore but not use MC association. In legacy software this was a requirement, as Moore didn't mess with MC.

Now that Moore does everything the point is lost and indeed functionality is better placed where needed.

On a different note but related to this point @erodrigu there are currently some open MRs (!898 (merged)) that import in functorcollections classes defined in DV (e.g. here) for printing the collections. I am wondering if the right place for functorcollections is in DV and not Analysis`. WDYT? (We can discuss this in that relevant MR, just thought I should bring this up here first).

Thank you for pointing this out. I had not spotted it. Sure, we can discuss that in the MR or in some other follow-up clean-up given all the ongoing discussions on project dependencies and related (DaVinci config related files in particular, with various duplications compared to what is in Moore).

@pkoppenb, it does seem odd to me and not the way I would at least naturally see the code organised.

In any case, if you agree with this concrete suggestion, will one of you take care of the MRs? I can do it but since I'm about to be on hols any action would have to wait ... Of course I can create and you then push to my branches. Up to you. I will see your decision if you assign this task to me :-).

mentioned in merge request Rec!3063 (merged)

mentioned in merge request !911 (merged)

mentioned in merge request !898 (merged)

closed with merge request !911 (merged)

mentioned in commit 5e25c304

mentioned in commit Rec@0227c7c9