Thomas Strebler authored 11 months ago and Tadej Novak committed 11 months ago

Explicitly configure MuonCalibTool in MetAnalysisConfig with calibMode

Baptiste Ravina authored 1 year ago and Frank Winklmeier committed 1 year ago

CPAlgorithms: provide default GRLs

Essentially this ensures that users don't misspell their selection
names, or use a selection name they forgot to define.

This is only for full selections, for preselections I don't do
it, as I usually ask for them before they are defined.  I also
don't do it for the baseline selection.  If that is not present
that just happens.

Oliver Majersky authored 1 year ago and Tadej Novak committed 1 year ago

Revert "Remove FTAG selectionNmaes that are actually never used."

This reverts commit 436ed695.

The main usage here is that if OR is run before MET we don't want to use the OR selections with MET.  A similar issue is expected to come up with fakes/fakeable objects, i.e. some specific baseline cuts should not be applied (in fact they are inverted), but only for very specific users.

The mechanism chosen here is to mark the cuts when they are registered and then exclude by name when requesting the selection.

Oliver Majersky authored 1 year ago and Johannes Elmsheuser committed 1 year ago

Rework interface for GRL and PRW block configuration in CP algos

Joseph Earl Lambert authored 1 year ago and Frank Winklmeier committed 1 year ago

Default blocks are added by default. PRW parameters are obtained from ConfigAccumulator.

Add autoconfigFlags as an attribute to the ConfigAccumulator so information can be
obtained in other blocks.

Update the PileupReweighting block so that campaign, input files, and useDefaultConfig
can be obtained from autoconfigFlags. The wrapper function that handeled this before has
been removed.

addDefaultAlgs function is now part of the ConfigFactory class and is called
automatically when initializing an object instance. Default parameters are now
obtained from ConfigAccumulator except for noSystematics flag so that this can
be changed from the command line if not specified directly.

Baptiste Ravina authored 1 year ago and Tadej Novak committed 1 year ago

CPAlgorithms: more user-side improvements

Baptiste Ravina authored 1 year ago and Walter Lampl committed 1 year ago

CPAlgorithms: allow Run4 settings for PHYSLITE development

Baptiste Ravina authored 1 year ago and Johannes Elmsheuser committed 1 year ago

CPAlgorithms: user-side improvements to the config blocks

Baptiste Ravina authored 1 year ago and Vakhtang Tsulaia committed 1 year ago

CPAlgorithms: change 'mc' to 'fullsim' in the config blocks metadata handling

This switches to the new configuration mechanism.  I had to add a
number of options to the blocks to make this happen.

Baptiste Ravina authored 1 year ago and Frank Winklmeier committed 1 year ago

CPAlgorithms: add flag autoconfiguration to ConfigAccumulator

Baptiste Ravina authored 1 year ago and Vakhtang Tsulaia committed 1 year ago

CP Algorithms: event cut flow

The primary thing this does is to introduce a SelectionNameSvc that
tracks the name of all the selection bits as reported by the various
selection tools, allowing to give much better labels for the
individual bins in the selection.  In addition this means I no longer
need to track the bits for each selection mask, as they get
automatically tracked.

I also added a configuration block for the cut flows (there wasn't one
yet), that allows to neatly add the cut flows when added.

The one breaking change is that this now requires a SelectionNameSvc
to get created.  I hope this doesn't cause too many issues.  In order
to minimize the effect of such changes in the future I introduced a
CommonServicesBlock (and corresponding sequence), to which I can add
more services as needed.

The main thing this does is to introduce an AsgUnionPreselectionAlg
that allows to combine systematics dependent selection flags into a
uniform preselection per systematic copy.  The logic here is that in
preselections I (typically) just want to filter out objects for
computational efficiency, but if the object fails for one systematic
on the shallow copy I anyways have to process it.  Having such a joint
selection decoration prevents the systematics of the selection to
propagate into outputs that would otherwise be unaffected by it.

This then in turn allows me to add such a decoration (on request) as
part of the overlap removal config, as that is the only config block
that has systematics dependent selection decorations.

I also added a bunch of options to the OverlapRemovalConfig to allow
changing the selection name to whatever the user wants/needs.

Teng Jian Khoo authored 1 year ago and Frank Winklmeier committed 1 year ago

More config block fixes

Teng Jian Khoo authored 1 year ago and Vakhtang Tsulaia committed 1 year ago

Define algorithms that cross-link nominal and systematic variations objects, and use these to build union selections

Teng Jian Khoo authored 1 year ago and Vakhtang Tsulaia committed 1 year ago

Make DualUseConfig/ConfigAccumulator CA-compatible and create CA FullAlgorithmTest instances

Baptiste Ravina authored 1 year ago and Tadej Novak committed 1 year ago

Clean up EventInfo variables in CPalgorithms

This should have been in there since the beginning, but there were
some minor issues.  Hopefully that is now resolved.

Baptiste Ravina authored 1 year ago and Tadej Novak committed 1 year ago

make the LHC Run period a global property of the ConfigAccumulator, rather than an option in each config block

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.

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

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.

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

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

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.

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).

This largely matches what was done for muons, but based on the tau
configuration.

Unfortunately the unit tests are not currently working and have
already been disabled in master.  I added more tests, but also
disabled those.

The main goal here is to provide a foundation on which we can build,
and that allows to quickly convert all the existing configurations, so
that we can drop the old configuration quickly and don't have to
maintain two parallel configuration mechanisms over an extended period
of time.

The interfaces and implementations will likely change, particularly as
we evolve the configuration to add another layer on top of it.  As
such the primary goal here is to provide a sort of stable interface
for the actual users of the CP algorithms, so that they don't have to
constantly update as we tune/change this.  I'd also like to keep the
actual structure of the configuration blocks sort of stable, but I'd
expect some degree of changes here over time.

The main ingredients of this configuration model are:
* ConfigBlock: The actual object specific configuration classes
  that have individual implementations for each group of algorithms that
  should...