athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2020-04-09T03:02:43+02:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/31759update to use the algorithm meta-configuration for jet selection2020-04-09T03:02:43+02:00Nils Erik Krumnackupdate to use the algorithm meta-configuration for jet selectionNot sure I got it completely correct, there was some more extensive
logic in here, but at least the tests seem to work.
It would probably be good to get some feedback from @tadej, @zmarshal, @jburr or @khoo who seem to have written the ...Not sure I got it completely correct, there was some more extensive
logic in here, but at least the tests seem to work.
It would probably be good to get some feedback from @tadej, @zmarshal, @jburr or @khoo who seem to have written the original configuration.https://gitlab.cern.ch/atlas/athena/-/merge_requests/31756update CP algorithm sequences to utilize meta-configuration2020-04-09T03:02:46+02:00Nils Erik Krumnackupdate CP algorithm sequences to utilize meta-configurationAfter adding meta-configuration and setting up the muon sequences with that in https://gitlab.cern.ch/atlas/athena/-/merge_requests/31663, this now updates the other object types (except for jets which do more complicated stuff).After adding meta-configuration and setting up the muon sequences with that in https://gitlab.cern.ch/atlas/athena/-/merge_requests/31663, this now updates the other object types (except for jets which do more complicated stuff).https://gitlab.cern.ch/atlas/athena/-/merge_requests/31465AnalysisTop: fixing the name of the KLFitter tool2020-03-26T03:03:53+01:00Marino RomanoAnalysisTop: fixing the name of the KLFitter toolCurrently, the name of the KLFitter tool, which appears in the cutflow, is `LeptonName_cutflowName` (for example `kMuon_passed_resolved_mujets_4j2b`). With this modification, it will be `RECO::KLFitterRun_LeptonName` (using the syntax fr...Currently, the name of the KLFitter tool, which appears in the cutflow, is `LeptonName_cutflowName` (for example `kMuon_passed_resolved_mujets_4j2b`). With this modification, it will be `RECO::KLFitterRun_LeptonName` (using the syntax from `TopEventReconstructionTools/Root/PseudoTopRecoRun.cxx`).
Since it is a very small change, I've deemed overkill to open a Jira ticket.https://gitlab.cern.ch/atlas/athena/-/merge_requests/30494introduce a common base class for components in AnalysisBase2020-03-04T03:03:17+01:00Nils Erik Krumnackintroduce a common base class for components in AnalysisBaseSo, I started developing a dual-use service base class, so that we could migrate from public tools to services where needed. This is particularly relevant as we move to release 22 where public tools are discouraged and services are the ...So, I started developing a dual-use service base class, so that we could migrate from public tools to services where needed. This is particularly relevant as we move to release 22 where public tools are discouraged and services are the designated replacement. However, building this I found myself replicating a lot of the configuration capabilities in `AsgTool` and `AnaAlgorithm`, something which would have to be repeated for dual-use re-entrant algorithm and any other dual-use component we may introduce in the future. So instead I created a common base class for all component types inside AnalysisBase, which reduces the complexity of implementing the component-specific base classes.
For now this is mostly moving code present created for `AsgTool` and `AnaAlgorithm` into newly created common base classes. There is some amount of cleanup that could be done in the future. We could also discuss/decide what sort of functionality we want in that common component base classes, or what we don't want, e.g. AsgTool allows users to change the name of the tool after initialization which doesn't seem like something we would want to allow. However, I do not want to do that discussion/cleanup as part of this merge request.
We could also discuss whether we want to introduce an `AsgToolConfig` class to allow for a simpler/more robust way of creating tools stand-alone, as an alternative and/or backend to `AnaToolHandle`. This could be dual-use, or only for `AnalysisBase`. Ideally that would even enable us to drop `AnaToolHandle` in master, as `AnaToolHandle` has unfortunately turned into a rather complex, fragile and confusing construct, and it isn't as needed anymore given that we now have dual-use python configurables.
I hope people agree with the general design, otherwise we probably can/should discuss this at the next AMG meeting.
cc @alister @lheinric @akrasznahttps://gitlab.cern.ch/atlas/athena/-/merge_requests/30781disable QuickAna in analysis releases2020-03-04T03:03:11+01:00Nils Erik Krumnackdisable QuickAna in analysis releasesSince QuickAna doesn't seem maintained any more, the best solution may
be to take it out of the release, but keep it in the repository (for
now). That way if somebody steps up to maintain it we can reinclude
it if needed, or if nobody m...Since QuickAna doesn't seem maintained any more, the best solution may
be to take it out of the release, but keep it in the repository (for
now). That way if somebody steps up to maintain it we can reinclude
it if needed, or if nobody misses it this would be the first step in
removing it completely.
This may/will need some discussion before it gets merged, but this will hopefully at least trigger that discussion.
cc @amehta @alister @lheinric @akrasznahttps://gitlab.cern.ch/atlas/athena/-/merge_requests/30682drop AthenaPoolExampleAlgorithms package from AthDerivation2020-03-04T03:03:12+01:00Nils Erik Krumnackdrop AthenaPoolExampleAlgorithms package from AthDerivationThere is no reason to have that package and its tests keep failing.
cc @akrasznaThere is no reason to have that package and its tests keep failing.
cc @akrasznahttps://gitlab.cern.ch/atlas/athena/-/merge_requests/3061721.2 Add resolution categories2020-02-28T11:15:59+01:00Magnar Kopangen Bugge21.2 Add resolution categoriesThis merge request adds a function to the MuonSelectorTool that allows categorization of muons according to their resolution as observed in MC samples with realistic detector misalignments. This will be used in an update of the MuonCalib...This merge request adds a function to the MuonSelectorTool that allows categorization of muons according to their resolution as observed in MC samples with realistic detector misalignments. This will be used in an update of the MuonCalibrationAndSmearingTool to allow more realistic smearing to be applied to muons that fail the high-pT working point and also to the 2-station muons currently accepted in the high-pT working point.https://gitlab.cern.ch/atlas/athena/-/merge_requests/30353fix for compiler warning (ATLASG-1503)2020-03-05T11:40:50+01:00Julien Maurerfix for compiler warning (ATLASG-1503)As ATLASG-1503 keeps showing up in the Egamma dashboard... I propose this most minimal modification of AnaToolHandle.icc in order to avoid the warning (+ possible unwanted compiler optimisation) and close the ticket.
Expected impact: n...As ATLASG-1503 keeps showing up in the Egamma dashboard... I propose this most minimal modification of AnaToolHandle.icc in order to avoid the warning (+ possible unwanted compiler optimisation) and close the ticket.
Expected impact: none, as the ToolHandle operators * and -> currently have identical implementation ([ToolHandle.icc](https://gitlab.cern.ch/atlas/athena/blob/21.2/Control/AthToolSupport/AsgTools/AsgTools/ToolHandle.icc)) and both actually raise an exception if the tool pointer is null.
Tagging expert @krumnack.https://gitlab.cern.ch/atlas/athena/-/merge_requests/28947eliminate automatic appending of `_%SYS%` to output names in CP algorithms2019-12-27T09:18:52+01:00Nils Erik Krumnackeliminate automatic appending of `_%SYS%` to output names in CP algorithmsWhen running without systematics this will otherwise append `_NOSYS`
which is rather annoying/unsightly.
Activating full unit tests, because I want to make sure this doesn't get called anywhere without `_%SYS%` without intending to do s...When running without systematics this will otherwise append `_NOSYS`
which is rather annoying/unsightly.
Activating full unit tests, because I want to make sure this doesn't get called anywhere without `_%SYS%` without intending to do so.
This will/ought to affect `PHYSLITE` derivations, by stripping out the suffix.
cc @tadej @zmarshalhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/27737Avoiding pFlow charge comparisons to zero and using isCharged() instead2019-12-02T19:33:21+01:00Chris Malena DelitzschAvoiding pFlow charge comparisons to zero and using isCharged() instead@mhodgkin reported in [ATLJETMET-796](https://its.cern.ch/jira/browse/ATLJETMET-796) that the charge of the pFlow object is compared to != 0.0 instead of using FLT_MIN. This has been hopefully changed now in all instances and also the co...@mhodgkin reported in [ATLJETMET-796](https://its.cern.ch/jira/browse/ATLJETMET-796) that the charge of the pFlow object is compared to != 0.0 instead of using FLT_MIN. This has been hopefully changed now in all instances and also the comparisons to 1e-9 where changed to FLT_MIN
A similar MR was created for release 21.0, see [27736](https://gitlab.cern.ch/atlas/athena/merge_requests/27736). A separate MR was used instead of picking targeting also 21.2 due to some file differences between 21.0 and 21.2
Also tagging @wbalunas, @williams and @khoo for their information.https://gitlab.cern.ch/atlas/athena/-/merge_requests/28101Allow the user to replace inputs and outputs for DL22020-02-03T18:05:50+01:00Dan GuestAllow the user to replace inputs and outputs for DL2It turns out there's a pretty good use case for non-standard inputs and outputs for DL2. This makes the tool more configurable.
Not quite ~urgent but hopefully will be in by the next release.It turns out there's a pretty good use case for non-standard inputs and outputs for DL2. This makes the tool more configurable.
Not quite ~urgent but hopefully will be in by the next release.https://gitlab.cern.ch/atlas/athena/-/merge_requests/27510JetAnalysisSequence: better support for PFlow jets and fJVT2019-10-29T03:03:12+01:00Tadej Novaktadej.novak@cern.chJetAnalysisSequence: better support for PFlow jets and fJVTAdd better support for PFlow jets and fJVT in `JetAnalysisSequence` and related sequences.
- update all tests to use PFlow jets
- add separate EMTopo jets tests
- add more flexibility for JVT and fJVT - control recalculation, selectio...Add better support for PFlow jets and fJVT in `JetAnalysisSequence` and related sequences.
- update all tests to use PFlow jets
- add separate EMTopo jets tests
- add more flexibility for JVT and fJVT - control recalculation, selection and efficiency calculations, separately for central and forward jets
- MET significance does not work without FJVThttps://gitlab.cern.ch/atlas/athena/-/merge_requests/27033Add OriginalAodCounts2020-03-09T15:37:20+01:00Dan GuestAdd OriginalAodCountsThere are quite a few rather cryptic copypasta recipes to calculate the number of original AOD events, all spread across various frameworks. It would make more sense to have this centralized in some way, since in general what analysts wa...There are quite a few rather cryptic copypasta recipes to calculate the number of original AOD events, all spread across various frameworks. It would make more sense to have this centralized in some way, since in general what analysts want is just something that gives the sum of events and event weights.
For reference:
- [link to similar code in `AnalysisTop`][1]
- [link to similar code in `xAH`][2]
- [link to similar code in `CxAOD`][3]
- [link to similar code in `XAMPP`][4]
- [link to similar code in `AsgAnalysisAlgorithms`][5]
I'm sure it's similar for `MxAOD`, `PxAOD`, `SUSYTools`, or any of the other frameworks in wide use. What none of these implementations provide is a framework-independent way to access the CutBookkeepers metadata.
[1]: https://gitlab.cern.ch/atlas/athena/blob/ba85524ce66b370e048cb57188119cbf5a7da343/PhysicsAnalysis/TopPhys/xAOD/TopAnalysis/util/top-xaod.cxx#L395-443
[2]: https://github.com/UCATLAS/xAODAnaHelpers/blob/c95e847f56a7b42cea647f2cefade19fea623a2b/Root/BasicEventSelection.cxx#L191-L295
[3]: https://gitlab.cern.ch/CxAODFramework/CxAODMaker/blob/2f97fc97a4cf6f7845d43a46e365ed6c25c6ea71/Root/AnalysisBase.cxx#L350-432
[4]: https://gitlab.cern.ch/atlas-mpp-xampp/XAMPPbase/blob/40e7d1a6d7086b0c9e8f6370a79208e2bd1ecd14/XAMPPbase/Root/MetaDataTree.cxx#L372-411
[5]: https://gitlab.cern.ch/atlas/athena/blob/21.2/PhysicsAnalysis/Algorithms/AsgAnalysisAlgorithms/Root/AsgCutBookkeeperAlg.cxxhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/25374Add a new PMGDecayProductsSelectionTool to PMGTools2019-10-24T03:03:19+02:00Tadej Novaktadej.novak@cern.chAdd a new PMGDecayProductsSelectionTool to PMGToolsMaybe I'm mistaken but there has never been a nice way to dump `TRUTH0`/`TRUTH3` to flat ntuples. I started porting my code to the CP algorithms and this is the first step which can also be used in standard jobs. Although this MR for now...Maybe I'm mistaken but there has never been a nice way to dump `TRUTH0`/`TRUTH3` to flat ntuples. I started porting my code to the CP algorithms and this is the first step which can also be used in standard jobs. Although this MR for now only contains one tool I plan to add more:
- a tool to select by PDG ID
- an algorithm to decorate parent and child information
The `PMGDecayProductsSelectionTool` selects particles if they satisfy the following requirements:
- they originate from one of the required initial particles
- they only decay through an allowed list of particles (optional)
/cc @lcorpehttps://gitlab.cern.ch/atlas/athena/-/merge_requests/2738321.2-AnalysisTop Indentation and style fixes in all packages2019-10-24T03:03:22+02:00Tomas Dado21.2-AnalysisTop Indentation and style fixes in all packagesThis MR is huge and is probably impossible to review. but all changes are only white space changes made by `uncrustify`.
I took care to run the script only on cpp files.
As a test I compiled all packages and ran a test that produced id...This MR is huge and is probably impossible to review. but all changes are only white space changes made by `uncrustify`.
I took care to run the script only on cpp files.
As a test I compiled all packages and ran a test that produced identical result as the previous version.
Each commit represents fixes in one folder (package).https://gitlab.cern.ch/atlas/athena/-/merge_requests/26870AT: Decorate Large-R jets with TAccept information from BoostedJetTaggers2019-10-02T03:02:20+02:00Oliver MajerskyAT: Decorate Large-R jets with TAccept information from BoostedJetTaggersThis concerns retrieving result of boosted jet tagging algorithms in AnalysisTop.
By default, specified taggers in config file result in a branch added in output NTuples with binary 0/1 tagger decision for each jet.
This MR adds decora...This concerns retrieving result of boosted jet tagging algorithms in AnalysisTop.
By default, specified taggers in config file result in a branch added in output NTuples with binary 0/1 tagger decision for each jet.
This MR adds decoration with the TAccept object converted to bitmap (more in this [twiki](https://twiki.cern.ch/twiki/bin/viewauth/AtlasProtected/BoostedJetTaggingRecommendation2017) that contains more granular information about the tagger decision, such that users have the ability to retrieve this information in their custom event savers.
Resolves ANALYSISTO-868Oliver MajerskyOliver Majerskyhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/26648unflipped DL1(r) evaluated with (some) flipped input variables2019-09-19T03:02:46+02:00Philipp Windischhoferunflipped DL1(r) evaluated with (some) flipped input variablesHi,
This MR fixes a bug that shows up when both flipped and unflipped versions of DL1(r) are scheduled. Currently, the input variables `(minimum|maximum|average)TrackRelativeEta` are not stored separately in the `BTagging` container f...Hi,
This MR fixes a bug that shows up when both flipped and unflipped versions of DL1(r) are scheduled. Currently, the input variables `(minimum|maximum|average)TrackRelativeEta` are not stored separately in the `BTagging` container for the flipped and unflipped versions of the tagger (see [here](https://gitlab.cern.ch/phwindis/athena/blob/release/21.2.73.0/PhysicsAnalysis/JetTagging/FlavorTagDiscriminants/Root/BTagJetAugmenter.cxx#L126-128)). Since the `BTagJetAugmenter` for the flipped tagger is scheduled _after_ the one for the unflipped taggers (see [here](https://gitlab.cern.ch/phwindis/athena/blob/release/21.2.73.0/PhysicsAnalysis/JetTagging/JetTagAlgs/BTagging/python/BTaggingConfiguration.py#L541) and [here](https://gitlab.cern.ch/phwindis/athena/blob/release/21.2.73.0/PhysicsAnalysis/JetTagging/JetTagAlgs/BTagging/python/BTaggingConfiguration.py#L547)), the input variables for the latter are overwritten and DL1(r) is _always_ run on `(minimum|maximum|average)TrackRelativeEta` belonging to the flipped version.
The fix implemented here follows suggestions by @dguest and seems to work fine at first glance. More testing is probably desirable.
Note that this problem affects derivations that schedule the flipped taggers, i.e. all FTAG-derivations. Physics derivations without the flipped taggers should not be compromised. This means that the FTAG derivations at the moment contain a strange variant of DL1(r), which is different from the one in the physics derivations _and_ also different from the tagger that was actually trained. I guess this is not really want we want for the next round of calibrations.
Any feedback is appreciated!
Cheers,
Philipp
CC: @guirriec @cschiavi @cpollard @lidiaz @sanmayhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/26616new egamma leakage corrections2019-09-19T03:02:48+02:00Baptiste Ravinabaptiste.ravina@cern.chnew egamma leakage corrections[Improved egamma isolation corrections](https://twiki.cern.ch/twiki/bin/view/AtlasProtected/IsolationLeakageCorrections#Improved_Isolation_Corrections) are set up, but the needed variables are only available in the derivations starting w...[Improved egamma isolation corrections](https://twiki.cern.ch/twiki/bin/view/AtlasProtected/IsolationLeakageCorrections#Improved_Isolation_Corrections) are set up, but the needed variables are only available in the derivations starting with p3947/p3948 (21.2.71.0).
I plan on keeping this MR as WIP until such TOPQ1 DAODs are available for testing, @tdado & @mvanadia.https://gitlab.cern.ch/atlas/athena/-/merge_requests/24913GCC 8 Warning Fixes, 21.2 branch (2019.07.16.)2019-07-18T03:04:17+02:00Attila KrasznahorkayGCC 8 Warning Fixes, 21.2 branch (2019.07.16.)Now that we managed to build a first successful AnalysisBase nightly for the `x86_64-centos7-gcc8-opt` platform (http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/GITWebArea/nightlies/21.2/2019-07-16T0755/Anal...Now that we managed to build a first successful AnalysisBase nightly for the `x86_64-centos7-gcc8-opt` platform (http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/GITWebArea/nightlies/21.2/2019-07-16T0755/AnalysisBase/x86_64-centos7-gcc8-opt/AnalysisBase/), it's time to start removing all the compilation warnings that it has.
Most of the updates in this MR are pretty harmless. I had to change the argument of many `catch(...)` calls to receive the exception objects by constant reference instead of by value. That's not a serious issue.
Many of the warnings in the nightly came from the `asg::AnaToolHandle` code. Both from some `switch(...)` statements not having a default clause, and also from one of the `catch...:` statements not ending in `break;`. A comment in the code made it clear that this was intentional from @krumnack. But GCC did not understand that comment. :stuck_out_tongue: However, as weird as it sounds, it did understand a different kind of comment... :confused:
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
At first I tried to use the `[[gnu::fallthrough]]` and `[[fallthrough]]` expressions to silence that warning, but those for some reason didn't work. But adding this sort of a comment to the code did. :stuck_out_tongue:
Finally, for the real issues:
- In the `TrigConfHLTData` package I had to make the same update that @ssnyder made in the master branch a while ago. And just to say... that code is weird... By now I don't think anymore that it's buggy, but I did think that for quite a while. The bitwise operations done in all the functions around the two that were actually buggy, and which were fixed in this MR, are ridiculous. :frowning:
- The update I made in the b-tagging code should really be looked at by some expert from that area. @tpelzer, could you have a look? And/or pull in anyone else that should? I tried to fix the code as best I understood it, but I could've easily be wrong with what the intention in that piece of code was.
Finally, I didn't touch the [QuickAna](http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/GITWebArea/nightlies/21.2/2019-07-16T0755/AnalysisBase/x86_64-centos7-gcc8-opt/AnalysisBase/PhysicsAnalysis.TopPhys.QuickAna.log.html) and [SUSYTools](http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/GITWebArea/nightlies/21.2/2019-07-16T0755/AnalysisBase/x86_64-centos7-gcc8-opt/AnalysisBase/PhysicsAnalysis.SUSYPhys.SUSYTools.log.html) packages. Though that may have been a mistake, as some of the warnings showing up there after these updates may still have to do with code outside of those packages...https://gitlab.cern.ch/atlas/athena/-/merge_requests/24504TauAnalysisTools: New Summer 2019 Recomendations2019-07-08T14:03:14+02:00David KirchmeierTauAnalysisTools: New Summer 2019 RecomendationsThis MR introduces a new recommendations tag "2019-summer", including:
* TauSelectionTool: implement new electron veto working points
* TauEfficiencyCorrectionsTool: updated systematics for old e-veto working points
* TauEfficienc...This MR introduces a new recommendations tag "2019-summer", including:
* TauSelectionTool: implement new electron veto working points
* TauEfficiencyCorrectionsTool: updated systematics for old e-veto working points
* TauEfficiencyCorrectionsTool: new systematics for new e-veto working points
* TauEfficiencyCorrectionsTool: first preliminary systematics for tau decay mode classification
* HelperFunctions: new helper functions to retrieve truth decay mode information
Details on the new electron veto recommendations can be found here: https://its.cern.ch/jira/browse/ATLTAU-1651
Details on the decay mode classification recommendations can be found here: https://its.cern.ch/jira/browse/ATLTAU-1636