Add ThOr functors to traverse decay tree (CHILD, INTREE, NINTREE etc.)

Depends on core development in Particle v2 class (parent-child relations), LHCb#159

CHILD functor added in !2573 (merged), works only with Particle v1.

marked this issue as related to LHCb#159

@mvesteri

added ThOr label

marked this issue as related to #228

Regarding the related issue Alejandro linked I would also like to add that the possibility to access information of the children from the parent object is needed for HLT2 trigger lines that use the MVA Functor. Personally, I am training a MVA on dilepton pairs, which uses the PT and MINIPCHI2 of the leptons as well as other inputs from the combination. Therefore, it would be important to have these functors to be able to test the trigger lines properly. @gligorov

@graven can I get your opinion on how easy this will be once your first version of the relations is ready?

assuming !2504 (merged) will work as expected i.e. it is possible to write generic 'forwarding' functors, which function like VFASPF did in LoKi, then it should be possible to write one generic bit of code to do the navigation, and separate it from the 'what it has to retrieve' part (where the latter would be a construction time argument to the former). In which case, it would be some work, but should be do-able... in the (unlikely!) case !2504 (merged) turns out to be impossible then it will be lots and lots of work.

mentioned in merge request Moore!1151 (merged)

mentioned in merge request Moore!1232 (merged)

mentioned in merge request Moore!1260 (closed)

Hi @poluekt, cc @amathad and @pkoppenb. As work on MC relations and functors for FunTuple is progressing full steam the interest in functors such as the ones in preparation in this MR will be in more demand, I can imagine. Can you drop a line on how you see this work here converge so that users can start exploiting these functors in studies? Advance thanks.

mentioned in issue #268

mentioned in issue #279

marked this issue as related to #279

added DPA-WP3 label

mentioned in issue #245 (closed)

I see there is a CHILD functor at https://lhcbdoc.web.cern.ch/lhcbdoc/moore/master/selection/thor_functors_reference.html#Functors.Functors.CHILD. Is that (partly) addressing this issue?

Yes, but AFAIK the core functionality is still missing for it to work with Particle v2.

removed DPA-WP3 label

mentioned in merge request DaVinci!756 (merged)

Hi @poluekt, @mvesteri, looking at the WIP dependencies of this MR, I was wondering whenever we have all the elements to define MINTREE, MAXTREE and NINTREE functors already using the composition (see this propose here).

Let me add also DPA and DPA-WP3 coordinators @erodrigu @pkoppenb to this message.

Please let me know what you think about it and if in case it is necessary to open a quick MR with the definition of these functors

cc: @graven, @amathad

Hi @tfulghes , Nice! Yes your proposed composition should definitely be added!

def MINTREE(predicate, functor): 
	return MIN_E @ MAP(functor) @ FILTER(predicate) @ FLATTEN

def MAXTREE(predicate, functor): 
	return MAX_E @ MAP(functor) @ FILTER(predicate) @ FLATTEN



def NINTREE(predicate): 
	return SIZE @ FILTER(predicate) @ FLATTEN


I will prepare a branch with these changes then!

Nice indeed.

I do repeat my comment that MIN_E and MAX_E should really be renamed because they are about Element, not Energy. The chosen name is very unfortunate and misleading. Can you take the opportunity to make this "fix" happen?

Question: What if I want to apply a cut on one of the composite particle in the decay tree?

The functor FLATTEN, as I understand it, returns all basic particles of the decay tree right ? (I understand it comes from LoKi, but it should really be named GET_BASIC_PARTICLES or something similar).

Anyway, above is a good starting point and one can latter replace FLATTEN with a new functor GET_DESCENDANTS to allow for my use case.

Oh yes I almost forgot that sorry @erodrigu! Since there were no further comment on the #396 (closed) I suppose we can go ahead with it.

Good point @amathad! For what regards the renaming of the FLATTEN functor let me tag @nnolte (if I remember correctly) as proposal of this one

And in the case that you specified I suppose it is necessary a functor that looks over all the particles in the decay tree, not only the basics ones

Thank you for the reminder that you had already created the task #396 (closed) .

Some quick comments following up latest updates on !3224 (merged). The MR itself is not yet completed, there are few additional tests that have to be done.

Up to now implemented there are:

• GET_ALL_BASICS -> returns all the basics from the decay
• GET_ALL_DESCENDANTS -> returns all children from the decay
• GET_GENERATION(x) -> returns all the children belonging to the x generation (with GET_CHILDREN=GET_GENERATION(1))

"Tree"-like functors are based on GET_ALL_DESCENDANTS, while "Generation"-like functors are based on GET_GENERATION

It was needed another mapping (for the moment named MAP_ONE_OF) with the opposite functionality of MAP_ALL_OF (i.e. doing a map of a predicate and early stopping whenever a true value is encountered) to implement INTREE and INGENERATION

What do you think about it so far?

Do you think it could also make sense for the selections to define also a MINGENERATION and MAXGENERATION functor not present in LoKi?

That's great. This effectively replaces the functionality of the ParticleDescendents tool, which however is still being used in many places. Just reminding myself here that ParticleDescendents cannot yet be removed until all its users are also modernised.

Can we rename MAP_ONE_OF to MAP_ANY_OF to be consistent with python and C++? Also, MAP_ONE_OF suggests that if more than one elements satisfies the predicate it would not pass...

mentioned in issue #433

mentioned in merge request !3224 (merged)

added DPA-WP3 label

mentioned in merge request Moore!1914 (merged)

Closed by !3224 (merged)

closed

removed the relation with LHCb#159