Revise Decay Finders

The Decay Finders used in FunTuple are too specific. They are different tools dependent on the input (MCParticle, Particle) while they do the same thing. This will not work once composites, charged and neutrals will have different types. We need to redesign how we match particles. It could be solely based on functor composition (but that's just one idea).

cc @graven @amathad

added DPA-WP3 Tuples labels

marked this issue as related to #36 (closed)

Note that redesigning/reimplementing this does not have to wait for Particle v2. Once it is generic enough to uniformly treat Particle and MCParticle, adding yet another version of Particle should be straightforward -- i.e. once we move beyond counting to one and are able to count up to two, counting to three won't be a novel concept, but just a minor variation on a theme.

assigned to @amathad

Assigning to @amathad as he volunteered today. Feel free to unassign if required.

mentioned in merge request DaVinci!695 (merged)

Moving the comment to here.

Question is on which decay finders should FunTuple rely on

There are few options:

• Simple HLT2 one: The HLT2 one is simple and does not support other features e.g. no hat (^) feature for selecting particles in the decay chain. Perhaps we do not want such a feature anyway since we can use F.CHILD functors (see the side-note below)?
• LoKi one: This is advanced and has lot of features developed for Run1/2. It makes sense to adapt it, but looking into it, the class has layers upon layers. If we want to go down this route, I need to chat with someone familiar with the code (perhaps Vanya?).
• Write our own: Instead of re-inventing we can rely on Hlt2 one and improve it.

Side-note on the hat(^) feature in decay descriptor for v2 in FunTuple:

Currently in FunTuple the type of the input particles form the signature of the input functors i.e. if the input type is Composites the functors will only operate on Composites. Now if we select for example a ChargedBasic with the ^ feature, we run into trouble. One can solve such an issue in few ways:

• Use F.CHILD functors: Users could still provide ^ to select particles, but on the python side we can simply wrap corresponding functors with F.CHILD. Easy option (?) and we keep Run1/2 behaviour.
• Add an additional layer: The first layer would sort inputs according to type, putting them in different TES location. Then we call corresponding FunTuple algorithm (e.g. FunTuple_Composites or FunTuple_ChargedBasics) with those separate inputs. In the end, we hadd the root files. This option is a bit ugly.
• Use of std::variant: Add a signature to ThOr functors to be inclusive e.g. std::variant<Composites,ChargedBasics,...>. Desired, however needs to figure out how to do this though.

Thanks for the summary @amathad

My only input is that there are legitimate reasons to support different decay finders in the combinatorics engine we use for production in HLT2 and when e.g. parsing MC decay trees to fill an ntuple with truth-level information. I would suggest that discussing with @ibelyaev who has thought about this as much as anyone on LHCb would be a good idea regardless of the solution you pick.

Also just to add, since the model for MCParticles will not change, we perhaps better-off relying on what already in place for those i.e. LoKi MCDecayFinder.

The right solution is a variation on 3, i.e. variant, but not std::variant -- we need something which is 'simd'-friendly. For the direction take a look at the code eg. here which in this case uses something that behaves as a variant (in this case ChargedBasics which is actually just a variant over different underlying types of track) to extract common information supported by all element types of the variant. The same strategy can be used 'one level up' as one basically has to query either Composite or ChargedBasic for the same information (eg. their PID -- just like in this example, different types of tracks are all queried for the number of degrees of freedom).

Also note, that one does not have to add anything to ThOr -- other than providing that this variant-like type has corresponding ADL implementations -- which is what the entire 'ADL' design was about: types get to 'opt-in' by adding the right signature to the relevant overload set. So this new type (which acts like a variant) just has to 'opt-in', i.e. one has to provide the right (ADL-findable) overloads for the relevant functions.

So in practice this is a matter of 1) defining the relevant type, and then 2) (as also done in the example I pointed add) add ADL-findable overloads which 'do like visit does' and which dispatch the call to the corresponding functions for the underlying types.

Another example, this time for the referencePoint implementation can be found here.

Thanks for the input on the variant Gerard. Will look through the links. Would indeed be good to add the variant signatures to the ThOr functors in FunTuple instead of individual signatures (Composites and ChargedBasics) like it is done now. Would circumvent the ^ issue.

For the DecayFinder issue indeed was going to adapt LoKi one or write a simple one using ADL functions (decayProducts(), pid(), etc). Tried using them on v2, particularly decayProducts(), but it did not work as I need the MR you linked (I think). Will anyway start with v1 + ADL, which can then be straightforwardly applied to v2.

-- indeed, the best strategy is to start with the V1 version, and then refactor (generalize) that implementation by using the ADL functions.

And yes, for v2 you'll need the MR I referenced -- perhaps another point to discuss is how to proceed with that MR, as 'as-is' it is not (yet) a complete replacement for the old v2, i.e. there is downstream code which will fail -- but on the other hand, that downstream code is actually tests which verify (and force!) a certain implementation, and thus that code will sooner or later have to go. So the question is, what is more efficient: remove it, and thus unblock the 'new' v2 MR even in an incomplete state, or keep it around, and only consider merging the 'new' V2 once it (at least) surpasses the 'old' v2 (including new&updated tests)? So far I've been hesitant on doing the latter, as until the new 'v2' is more complete it may still change, but with the work on the decay finder, it may be better to be more aggressive in dropping the 'old' v2 and find out by using it (also) there what is a good idea, and what isn't... (and work on completing the 'new v2' MR is prioritized below the persistency changes, so it has stalled over the last few weeks)

Note that the 'old v2' is really a dead-end, as the fact that it is 'zip-based' will just not work with the generic persistency...

mentioned in merge request !888 (merged)

assigned to @sabarre

@sabarre (summer student): Is now working on this.

Hopefully the tools developed here could have some commonality with the F.MCMATCH(<MC decay descriptor>) discussed in another issue.

Cool, welcome ! [You meant "now" ;-).]

Morning @amathad, @sabarre, it was great to see at yesterday's WP3 meeting your excellent progress .

In case you overlooked or forgot, there's this long-standing issue #22 (closed) that totall relates to your work here. I suggest you take this on board as a built-in feature and close the isse. Just comment or act as you see fit. Advance thanks.

Thanks @erodrigu . Indeed will take on board.

mentioned in issue #25 (closed)

marked this issue as related to #22 (closed)

Is this completed?

There is an issue in Rec with DPA_WP3 label: Rec#398. So feel this can be closed.

closed