Draft: manual sweep of block configuration from master
- Jan 30, 2023
-
-
Nils Krumnack authoredThat seems to address the differences between sequence and block configuration. If this is the right thing to do is a different question, left to the experts.
b61d5d99 -
Nils Krumnack authored
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.
ce4215a0 -
Nils Krumnack authored
Switched it to the British spelling and provide a useful error message when the American spelling is used.
96cfdb97 -
Nils Krumnack authored
That allows to instantiate them in a more uniform manner, duplicating what has already been done for muons and photons.
cf0e307f -
Nils Krumnack authored
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.
e20fb655 -
Nils Krumnack authored
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.
bea5f416 -
Nils Krumnack authored
That's needed to run the filter algorithms in Athena.
0e8d7cd1 -
Nils Krumnack authored
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.
47171c1f -
Nils Krumnack authored
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.
7fe467da -
Nils Krumnack authored
This allows to have e.g. tight muons above a pt of 50 and loose muons for any pt.
73007312 -
Nils Krumnack authored
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.
bee3d675 -
Nils Krumnack authored
Sometimes it is necessary to combine multiple selections into one to achieve what is needed/wanted.
16d8bf89 -
Nils Krumnack authored
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.
ab744557 -
Nils Krumnack authored
That fixes a bug introduced in !55866, and is anyways what ought to be done.
ac1e9329 -
Nils Krumnack authored
Essentially I now need to include the const modifier directly in the template type. The idea is that this allows future iterations of the handle to do different things based on whether they will provide read access or update access.
b3605768 -
Nils Krumnack authored
This is mostly a combination of what is in the full sequence test and what is done in the MET config.
10595cc3 -
Nils Krumnack authored
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".
6bf221ec -
Nils Krumnack authored
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.
f290ec30 -
Nils Krumnack authored
This is mostly meant to allow easier comparisons of the generated sequence to spot differences more easily.
f47f3136
-