Add neutral truth matching from raw

Add neutral truth matching from raw (was only done from reco before)

added Calo label

Thank you! I'm very happy to see this.

We do have relations tests (Hlt2Conf.test_hlt2_relations and Hlt2Conf.test_hlt2_relations_full_mc) but they are currently disabled because the test that produces their input is also disabled (#234 (closed)). Relations feel very fiddly to me so I worry how little coverage we have for this new MR. I will try to look into re-enabling these tests.

---

There are two parts that worry me in the code. This

        clus = _collect_dependencies(neutral.producer, CALOCLUSTERS_V2_T)
        assert len(clus) == 2, "Unexpected number of clusters dependencies"
        clusters = clus.pop()
        splitClusters = clus.pop()
        if "SplitCluster" in clusters.location:
            clusters, splitClusters = splitClusters, clusters

and this

        hyp = _collect_dependencies(neutral.producer, CALOHYPO_V2_T)
        assert len(hyp) == 2, "Unexpected number of hypotheses dependencies"
        photons = hyp.pop()
        pi0s = hyp.pop()
        if "MergedPi0" in photons.location:
            photons, pi0s = pi0s, photons

It's good that the 'objects to relate' are retrieved from the data dependency tree of hte line candidates (using _collect_dependencies), but it's not nice that you have to split out split/non-split clusters and photons/pions from the results.

The way of distinguishing between each case using the location works today but may not in the future; in principle the location property is a random string, it just happens to contain the algorithm name today.

It would be great to make the configuration agnostic to the differences between split/non-split clusters and photons/pions.

Clusters

Both the split and non-split clusters get converted to v1 objects. The non-split v1 clusters are used to convert the photons to v1 hypos. Both split and non-split v1 clusters are used to convert the pions to v1 hypos.

Could the converters be modified to accept a list of v1 cluster containers? The converter algorithm can presumably categorise clusters by split/non-split internally (I'm guessing a cluster has a split flag or something). So we can have:

clusters = _collect_dependencies(neutral.producer, CALOCLUSTERS_V2_T)
clusters_v1 = [LHCb__Converters__Calo__Cluster__v1__fromV2(InputClusters=c) for c in clusters]
photons_v1 = LHCb__Converters__Calo__Hypo__v1__fromV2(
    InputHypos=photons,
    InputClusters=clusters_v1
)
pions_v1 = LHCb__Converters__Calo__Hypo__v1__MergedPi0__fromV2(
    InputHypos=pi0s,
    InputClusters=clusters_v1,
)

An alternative would be to write a small algorithm which accepts a list of clusters and spits out a list of split clusters and a list of non-split clusters:

clusters = _collect_dependencies(neutral.producer, CALOCLUSTERS_V2_T)
clusters_categorised = ClusterCategoriser(Input=clusters)
# Use the 'split' output of the categoriser
clusters_split_v1 = LHCb__Converters__Calo__Cluster__v1__fromV2(InputClusters=clusters_categorised.SplitClusters)
# Use the 'non-split' output of the categoriser
clusters_merged_v1 = LHCb__Converters__Calo__Cluster__v1__fromV2(InputClusters=clusters_categorised.MergedClusters)
# Now use split/non-split as you like
# ...

Hypos

I think you can use similar principles here as for clusters. Either:

1. Have hypo-accepting algorithms accept a list of hypos and filter them internally to whatever type you want to act on.
2. Have a single categoriser algorithm which provides handles on the categories of hypos you need.

---

I know all that seems rather convoluted. It's based the idea of removing as much knowledge from the configuration as possible. In this case I would like the knowledge of split/non-split clusters and photons/pions to move from the configuration to the C++.

How painful do you think these ideas will be to implement?

Thanks for your inputs. I think that the only way of categorizing split clusters/non-split clusters containers without looking at the name is to look at the type of the objects inside the container. Same for CaloHypos: we could probably check the hypo->Hypothesis() inside the containers to know whether the input container is made of Photons or Pi0Merged. Now I'm not sure where we would like to do that: Should we do that directly in the converters (CaloFutureReco)? or is it better to have a separate alg? I would also like to have the input from @graven on that.

resolved all threads

added 1 commit

• fd0d9a8a - Apply 1 suggestion(s) to 1 file(s)

Compare with previous version

added 1 commit

• b2e42c9a - Neutral truth matching modifications

Compare with previous version

added 1 commit

• 60674123 - Fixed formatting

Compare with previous version

added 413 commits

• 60674123...55218bfc - 403 commits from branch master
• 9a10be44 - Add truth matching from raw
• f7bad5b8 - Fixed formatting
• 97a5d479 - Few fixes
• 32e19524 - Few fixes
• 664d94e7 - Modified calo objects access
• 622e6590 - Fixed formatting
• 1601deed - Few fixes
• 3cbfe984 - Neutral truth matching modifications
• 719cc9a1 - Fixed formatting
• 991e1da6 - Merge branch 'jmarchan-neutralTruthMatching' of...

Compare with previous version

FYI @poluekt @mvesteri this is the MR adding MC matching for neutral objects when running the reconstruction in Moore. Shall we assign a new reviewer taking over @apearce on this topic?

added MC checking new feature labels

added 1 commit

• 4541d817 - Modified tables nomes

Compare with previous version

added 128 commits

• 4541d817...c5cadc07 - 114 commits from branch master
• 063f05b1 - Add truth matching from raw
• e2e1c28e - Fixed formatting
• 19143713 - Few fixes
• 43acea81 - Few fixes
• 3612e32f - Modified calo objects access
• 33425e94 - Fixed formatting
• 85f308a1 - Few fixes
• 6bf426d5 - Neutral truth matching modifications
• 2a6af484 - Fixed formatting
• 2d0b923b - Modified calo objects access
• f2d41073 - Fixed formatting
• 7862678f - Neutral truth matching modifications
• ce92231e - Fixed formatting
• d2ad4636 - Modified tables nomes

Compare with previous version

added 1 commit

• 36bd48b6 - v1 and v2 from _collect_dependencies

Compare with previous version