The main thing this does is to split the comparison tests between
sequence and block configuration into three tests each to allow the
block and sequence jobs in parallel and then run the comparison
subsequently.  With this working I went ahead and then used the same
test structure in AnalysisBase as well.

This also required some minor fixes, as well as putting in some tests
in a disabled state, because logically they ought to exist, but they
are not working and were not present/disabled up to now.

Apparently this should not be run for EMPFlow jets.

This is mostly meant to allow easier comparisons of the generated
sequence to spot differences more easily.

This allows to fully configure the output n-tuple via
block-configuration, and it allows to add a suggested list of
variables from the invidual blocks that define them, instead of having
to maintain that list outside of the configuration block
infrastructure.

Switched it to the British spelling and provide a useful error message
when the American spelling is used.

In particular this is needed to run flavor tagging on PHYSLITE.

That allows to instantiate them in a more uniform manner, duplicating
what has already been done for muons and photons.

This tries to give the same treatment given to muons and photons to
all the other configurations, so that it should be possible to
configure all the blocks just through the options.

There is probably some cleanup that could be done here in the future,
regarding what some of the configuration blocks should be called
exactly, what the options exposed should be etc.  The main goal of
this update is that I can now (more or less awkwardly) set everything
I can via options that was previously limited to named parameters to
the various make...Config() calls.

I also added customizable behavior for setting a value of `None` on an
option.

That's needed to run the filter algorithms in Athena.

This file defines a factory method that can create a configuration
block sequence based on a passed in name.  This avoids having to
import all the various config block sequence makers in the
configuration code, and also would make it easier to create them
from a text configuration file.

This relies heavily on the blocks exposing all configurable
parameters as options, since there is no other mechanism to
configure them through this interface.

The implementation itself is probably not the best possible, it
lacks all extensibility, gathers all information in a single place,
etc.  Still for now this ought to be good enough.

This is essentially a heavily modified version of
AsgxAODNTupleMakerAlg for the specific purpose at hand, i.e. writing
out MET variables as `float` instead of `std::vector<float>`.

There is probably some overlap of code with the original algorithm,
but I'd rather clean that up at a later point, as I anyways have to
revisit how I handle the output n-tuples in a better way.

So far the OutputThinningConfig required to put in an actual selection
decoration name to select which objects to keep.  That's not ideal,
because at the configuration level we often want to use the abstract
name of selections instead of the name of specific decorations on the
objects.

Sometimes it is necessary to combine multiple selections into one to
achieve what is needed/wanted.

Essentially I'm doing nothing, but enough needs to be done that
subsequent algorithms have shallow copies, know what the container
name is, etc.

I also did minor fixes for the large-R jet configuration, but had some
problems with the input containers in the input files.

The basic idea/goal of configuration blocks is that the configuration
system can read a configuration text file and then configure the
blocks accordingly.  This is made a lot simpler if the configurable
options on the blocks can be set via a uniform interface.

This is just a first draft of such a mechanism that allows to add the
options and set them by name from the python side.  All I want from
this MR is a basic interface that allows to add the options on the
individual blocks and set them through a python interface.  That will
then allow me to update all the configuration blocks to expose options
before I move on.

The mechanism for setting option values is even more rudimentary,
doing just the minimal thing to allow setting the properties through a
standard interface.  This is mostly there to allow me to move forward
somehow, but some details may change.  The interface I have right now
is probably not ideal for anybody, neither for the text nor the python
configuration.  That probably needs some changing at some point.

There is a much more sophisticated prototype available, but because of
its complexity I didn't want to incorporate it into this first draft.
Instead the interface I have should be (mostly) compatible with the
interface that prototype exposes.  It can then be retrofitted in here
at some point.  The full prototype is here:
https://gitlab.cern.ch/jburr/configblock/-/tree/master/

Also: For photons the recomputeIsEM option should probably not be
repeated in both the calibration and selection blocks.  There needs to
be a special method for forwarding options from one block to the next
which will come in a future update, or when the full option mechanism
gets incorporated here.

This is an adoption of the event selection sequence that pre-existed
and replaces the vertex selection configuration block.

This is mostly a combination of what is in the full sequence test and
what is done in the MET config.

This is a fairly straightforward copy of the sequence version, with
some extras to pass information behind the scenes.  The one cute
feature is that the selection name can be specified as
e.g. "AnaMuons.medium".

This involved a bit of tweaking everywhere, including to make sure I
actually have the kinematic selection build in and not making a view
container for them.

Chris Malena Delitzsch authored 2 years ago and Tadej Novak committed 2 years ago

Removing PFlow-Muon OR in R22

Jon Burr authored 2 years ago and Walter Lampl committed 2 years ago

Allow setting container selections directly in the MET maker

Nils Krumnack authored 2 years ago and Nils Erik Krumnack committed 2 years ago

If I want to do everything via blocks, this is one I need.

This is still very basic, but so is the sequence version.

That will be needed for most actual jobs, so it is good to have.

This now makes most algorithms work on PHYSLITE, and the ones that do
not work can be turned off.

This adds some tweaks to improve the performance of the sequence, some
extra variables commonly used, and allow running trigger selection
without filtering.

Teng Jian Khoo authored 2 years ago and Edward Moyse committed 2 years ago

Update jet analysis algs with NNJVT

Mostly based on what I did for the leptons and the existing jet
sequences.

Those were already there, just needed to be updated.

These are based closely on the ones for the electrons, with the code
from the current photon sequences.

This is mostly a transcribing of the electron sequence in the style of
the muon configuration block.

This is now hopefully more straightforward than it was, and should
allow future refactoring as needed.

This removes all the implicit views created by the various sequences,
and instead creates explicit views as inputs for MET and OR.  And it
adds actual consistent thinning for all containers for the output.
And it adds pt/eta cuts for all the objects, which are probably way
off from what they should be...

I also had to add some extra configuration options/decorations to some
of the sequences to make it all consistent.

This is mostly a collection of all the algorithms tests from the
various CP algorithm packages loosely stitched together.  It probably
will need some more cleanup at some point, but it at least provides a
baseline to test the configuration blocks against as I develop them.

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.

This is hopefully very straightforward, but also very incomplete: The
idea is that to validate the config blocks, I produce the same n-tuple
once with the config blocks and once with the sequences and then
compare it.  That validates that (at least for the chosen settings and
variables) both configurations are the same.  As a bonus, once
completed this also runs a fairly complete CP algorithms job in CI.

So far this is very incomplete, it only runs muons and only checks the
four-momentum, but having this in the release should allow adding more
objects and variables as I add more configuration blocks.

Given that the first iteration of the configuration block design
invoked criticism of the "reference" design for tracking containers I
now changed it, so that instead of first allocating references to
determine what the intermediate containers are, I just run through the
entire configuration twice.  The second run-through then can rely on
what it learned in the first run-through to determine what will happen
further down in the sequence.

This requires routing a number of calls through the ConfigAccumulator
object, but it definitely makes writing the actual blocks more
straightforward, and it should also allow for more flexibility if we
need to redesign the ConfigAccumulator in the future (which also
became simpler with this change).