Create and persist MC association tables
We now associate ProtoParticle objects selected by lines to MCParticle objects when running an MC DST. This works for line candidates and extra outputs (TurboSP).
If the line outputs refer to the reconstruction from the file (produced by Brunel), the associations are built up using the LinksByKey
objects from the file (produced by Brunel).
If the line outputs refer to the Moore reconstruction, the associations are created from the ground up using the lower-level associators already in Moore.
The default behaviour is to filter the associated MC objects under /Event/HLT2
(i.e. a microDST-like behaviour). This can be toggled with a bind
. There are tests for both methods. (The test for the 'full MC' method requires !591 (merged) to propagate the MC from the input file to the output, so will fail before that is merged.)
Association is not currently supported for neutral objects when running the Moore reconstruction. I am waiting for CaloHypo associators using the v2 CALO event model before working on that (@graven @ozenaiev).
Related changes
This work required a couple of other bits and pieces. In no particular order:
- There is now a test (
hlt2_lines_reco_mix
) which runs a single HLT2 job that has some lines taking the reconstruction from the file (Brunel) and some lines taking the Moore reconstruction. These are used to check that the truth-matching correctly disentangles theProtoParticle
objects for both sources, but as a side effect also tests that this dual reconstruction scenario is possible (we assumed it would be, and now we know💯 ). - The HLT2 output documentation has been updated to explain how to use the persisted relations tables. See here for a preview.
- Configuration which uses linker tables created in Boole or Brunel now call specific entry points,
Hlt2Conf.data_from_file.boole_links
andHlt2Conf.data_from_file.brunel_links
, rather than each callingFetchDataFromFile
in an ad-hoc manner. See e7ac2bf3. - The configuration of the Run 2 jet algorithms was changed a little to avoid reusing an existing property name, which prevented data dependency tree traversal. See 7605cc0f.
This sits on top of !591 (merged). That should be merged first.
Requires Rec!2172 (merged) and Phys!761 (merged). The pipeline will fail before these two are included in lhcb-head.
Closes #197 (closed). (OK not completely, but let's close it and open new issues for what remains.)
Requires MooreAnalysis!20 (merged)