Stefano Manzoni authored 2 years ago and Frank Winklmeier committed 2 years ago

Update PhysicsAnalysis/Algorithms/EgammaAnalysisAlgorithms/python/ElectronAnalysisSequence.py, PhysicsAnalysis/Algorithms/EgammaAnalysisAlgorithms/python/PhotonAnalysisSequence.py

This goes back to an old discussion that in principle AsgSelectionAlg
should not have a SysCopyHandle, as it doesn't introduce new momentum
systematics.  The reason it has one currently is that if there is a
selection before the correction algorithm it does need to make a
shallow copy that can then subsequently be modified at will.

The solution implemented here is what we discussed back then: To
implement an algorithm that does nothing more than make a shallow copy
(based on the view container algorithm and the copy mechanism from
SysCopyHandle) and schedule that before AsgSelectionAlg as needed.

Essentially the idea here is that this makes it easier to build
additional configuration layers on top, since it makes this more
composable.  In particular it means that multiple working points can
be added to a single sequence without having to do some complicated
special handling to deduplicate the calibration part of the sequence.
I also purposely pass in the actual sequence I operate on instead of
creating them internally, which (hopefully) gives the caller some more
freedom as to what that sequence may look like.

I didn't try to do anything particularly clever in splitting the
sequences up, and some cleanup could be sensible at some point.
Basically I split the sequences into three parts:
* calibration: any algorithms that can be shared between multiple
  working points
* working point: any algorithms that do things specific to a
  a working point that can't be shared between object types
* post processing: any algorithms that can be shared between multiple
  object types (essentially container copies and debugging histograms)

There is one algorithm that could go into either the working point or
the post-processing, and I chose working point: And that's the
algorithm that collects all the decorations for that working point and
makes an overall selection decoration for that working point.  My
reasoning here being that while that is a completely generic algorithm
it is still something we will always want to do and that the working
point sequence will feel incomplete if we leave it out (unlike the
post processing which the user could easily do his own way).  If we
find that is not the case we could move this around later on (or make
it optional).

Also, I found that at least in some places we have two types of
selections: One for the analysis object selection and one for the
output object selection.  For simplicity/consistency I just forced
that on all sequences, but it may be worth revisiting at some point.

I also had to do some amount of reordering to fit into this overall
scheme.  Most notably the e-gamma sequences did one of their WP specific
selections before running calibrations.  I flipped the order (at least
for now), as this is essentially a performance optimization (skipping
calibration for some objects) and we can bring it back later if we
decide that such an optimization is worth the headache it brings with it.

I also updated the photon sequence no longer to use view-copies
internally, but instead rely on preselection decorations.  Since that
is the way we said all sequences ought to have been working already
that seemed like a sensible change.

I also put the preselection configuration into the tau sequences.
Technically that is not used, but it allows pre-loading preselection
algorithms.

I'm not sure how sensible my updates to the di-tau sequence are, but
the original sequence was neither functional nor complete.  The unit
tests for that sequence were already commented out, and the sequence
itself doesn't even contain a selection algorithm.  Still I tried my
best to update it, to reduce future work.

I did leave the original top-level function around, calling the new
functions as they ought to be called.  That is mostly ment for
backward compatibility and it ought to be fine to call the new
functions directly as a user (though they may see more updates to
calling conventions than the top-level function).

Just to allow easier sequence modification.

Lukas Ehrke authored 4 years ago and Adam Edward Barton committed 4 years ago

The AsgElectronSelectorTool is migrated to master. Additionally the lwtnn
interface is changed to one which doesn't rely on maps as input.

Some of the clients may have been okay just staying with their current code,
but I wanted to harmonise all of them while I was at it.

Originally I had tried sweeping/cherry-picking this from 21.2, but
with all the three-way merges and commits that involve other
packages/directories that was rather painful, so this is now just a
direct copy from the current state in 21.2.