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

Explicitly configure MuonCalibTool in MetAnalysisConfig with calibMode

Stylianos Angelidakis authored 11 months ago and Tadej Novak committed 11 months ago

Update MuonSelectionTool

Joseph Earl Lambert authored 1 year ago and Walter Lampl committed 1 year ago

ConfigBlock: remove groupName, change noneAction, and duplicateAction

The groupName variable was changed to blockName and set from a
set/get function.

Add instanceName to identify specific instances when there is a
desire to set the value of an option in an arbitrary location and
there is more than one instance of a block.

Removed code to potentially throw an error if an option was
set more than once.

Instead of haing the user say "I am setting this option to None
and it is okay," the noneAction variable can be set when adding
an option. If the author of a class determines that an option
can be set to None, then they can set this for that option.

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.

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

CPAlgorithms: expose "excludeNSWFromPrecisionLayers" to the muon config

- /PhysicsAnalysis/Algorithms/MuonAnalysisAlgorithms/python/MuonAnalysisConfig.py
- /PhysicsAnalysis/Algorithms/MuonAnalysisAlgorithms/python/MuonAnalysisSequence.py

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

CPAlgorithms: allow Run4 settings for PHYSLITE development

Christos Anastopoulos authored 1 year ago and Edward Moyse committed 1 year ago

xAODMuon : Try to split the enums in a separate dict ATLASRECTS-7789

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

CP Algorithms: Update postfix used for ftag, electron WP, etc. to selectionName.

The name postfix is used for many of the CP config blocks as second arguement to the
initialization but the postfix often corresponds to the name given to the selection
name in other CP blocks such as MET and overlap removal. Inorder to make the name
more meaningful, it has been changed to selectionName.

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

CPAlgorithms: add flag autoconfiguration to ConfigAccumulator

According to @gwatts it would be "amazing not to have to run
calibrations on PHYSLITE".  So here we go: This adds options to jets,
e-gamma, and muons to skip the calibration where possible.  This means
no calibration is run for jets, and for e-gamma and muons the nominal
calibration is skipped.  Either way, this is probably most noticable
when running with systematics turned off, but even then the savings
may be smaller than what MET alone costs us to run.

I did enable some comparison tests for PHYSLITE jobs that were
previously commented out (the data one failed, so I left it commented
out), but didn't enable the new feature until it is fully validated
(read: those tests did fail).  I'm leaving it to the PHYSLITE experts
to do the validation and then turning this on by default in a separate
MR.

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.

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

Harmonise the noEffSF option amongst config blocks

During my previous changes I had to realize that our tests don't flag
columns disappearing, which is not ideal.  This now adds the option to
check for that as well.  I added that as an option so as not to change
existing behavior.

I enabled that for the CP algorithm checks, but had to disable some
columns that the sequence configuration didn't have at all or had
different results.  I'm not sure if it is worth fixing this (given
that the sequence configuration is on its way out), but if so this
should be part of a future change (given that it currently also
doesn't get checked).

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

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

Updates to muon algorithms

Jackson Carl Burzynski authored 1 year ago and Adam Edward Barton committed 1 year ago

Update muon CP alg sequence to latest Run 3 recommendations

R D Schaffer authored 1 year ago and Edward Moyse committed 1 year ago

setting up flag to avoid d0 and z0 cut for PhysLite, default remains apply cut

Oliver Majersky authored 2 years ago and Frank Winklmeier committed 2 years ago

Allow muon isolation WPs in the muon analysis sequence in CP algos

Zach Marshall authored 2 years ago and Walter Lampl committed 2 years ago

Broadening default muon selection for muon CP tools

Based on a thread on the AMG list, broadening the muon selection to 2.7.
This should be safe, as tighter working points will come with a tighter
default selection (e.g. medium requires eta<2.5), but will allow people
to use standalone muons beyond 2.5 if they exist. Will result in a very
small increase in PHYSLITE size.

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.

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.

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.

Teng Jian Khoo authored 2 years ago and Tadej Novak committed 2 years ago

Switch muon CP algs to correct muon SFs for Run 3

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 now makes most algorithms work on PHYSLITE, and the ones that do
not work can be turned off.

James Catmore authored 2 years ago and Adam Edward Barton committed 2 years ago

Draft: add code to allow DAOD_PHYSLITE to be made from PHYS with the component accumulator

This MR adds the small amount of extra python needed to allow PHYSLITE to be made from PHYS using the Derivation_tf transform, that is, the component accumulator. It touches three parts:

1. MuonAnalysisSequence has an extra argument allowing the internally produced MuonSelectionTool to be set to run 3 geometry should the input be data18/mc20. If this isn't done the tool crashes. This doesn't happen with AOD->PHYSLITE, presumably because the properties are inherited from the MuonCommonConfig, but this isn't used for PHYS->PHYSLITE
2. DerivationSkeleton is slightly adjusted to accommodate the different arguments, and also to create a new ConfigFlag called Input.FileType (currently can be AOD, DAOD_PHYS, EVNT)... this may be useful for other applications as well
3. PHYSLITE.py adjustment itself to put in guards to ensure that code that only works with AOD input (e.g. writing common physics content and re-setting MET association) isn't scheduled. It largely uses the new FileType ConfigFlag to achieve this. Also it sets the relevant geometry in the MuonAnalysisSequence.

With these changes, the following command works

```
Derivation_tf.py --CA --inputDAOD_PHYSFile filename.pool.root --outputD2AODFile output.pool.root --formats PHYSLITE
```

On account of the disabling of the MET association, the output is not yet usable for physics analysis. However, it still makes sense to prepare this MR to allow testing of this workflow, which will be needed during run 3.

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.

Johannes Junggeburth authored 2 years ago and Frank Winklmeier committed 2 years ago

MuonMomentumCorrections - Remove depricated tool MuonCalibrationPeriodTool

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

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 be configured as an indivisible unit.
* ConfigSequence: A sequence of blocks, though technically this could
  just be a simple python list instead.
* ConfigAccumulator: A helper object that is used to track all the
  information needed to communicate between (and within) blocks.
* container references: Helper objects that track all the shallow copies
  belonging to the same logical object.  This is taking the place of the
  current post-configuration step, essentially front-loading the
  connections between blocks.