athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2022-05-16T21:45:14+02:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/53298Added disd of 13.6 TeV ttbar and Zprime2022-05-16T21:45:14+02:00Binbin DongAdded disd of 13.6 TeV ttbar and ZprimeAdded DSID of new MC 13.6 TeV ttbar and Zprime to correctly save information for the new samples for physics validation.
tagging @juhofer , @duperrin and @thuffman .Added DSID of new MC 13.6 TeV ttbar and Zprime to correctly save information for the new samples for physics validation.
tagging @juhofer , @duperrin and @thuffman .https://gitlab.cern.ch/atlas/athena/-/merge_requests/53191Add GN1 to derivation config2022-05-16T21:42:18+02:00Samuel Van StroudAdd GN1 to derivation config- Preparation to add GN1 to derivation config (this will be done in a new MR once the files are in the group area)
- Store track `leptonID` as `char` instead of `int`
- Changing ONNX output level from warning to error (at some point we s...- Preparation to add GN1 to derivation config (this will be done in a new MR once the files are in the group area)
- Store track `leptonID` as `char` instead of `int`
- Changing ONNX output level from warning to error (at some point we should figure out how to remove the warnings about unused nodes)
There are leftover errors since the GN1 paths are still in the dev area. Perhaps @pgadow can move them to the group space?
@dguest @nkakatihttps://gitlab.cern.ch/atlas/athena/-/merge_requests/53095adding support to have leptonID as a track input for FTAG2022-05-10T21:42:29+02:00Nilotpal Kakatiadding support to have leptonID as a track input for FTAG- adding regex for `leptonID`
- Error message update for unknown `EDMType`- adding regex for `leptonID`
- Error message update for unknown `EDMType`https://gitlab.cern.ch/atlas/athena/-/merge_requests/52698Resolve ATLASRECTS-4365 "Ftag delete calibrationbroker "2022-04-29T11:47:28+02:00Arnaud DuperrinResolve ATLASRECTS-4365 "Ftag delete calibrationbroker "Cleaning as part of resolving ATLASRECTS-4365 from FTAG area.
This MR delete the CalibrationBroker tool and its clients as discussed in the ticket and during last SW FTAG meeting with @filthaut, @dguest et al.
CalibrationDataInterface...Cleaning as part of resolving ATLASRECTS-4365 from FTAG area.
This MR delete the CalibrationBroker tool and its clients as discussed in the ticket and during last SW FTAG meeting with @filthaut, @dguest et al.
CalibrationDataInterfaceROOT is the main (low-level) interface used now.
Tagging: @vdao @biliu @thuffman @pgadow @mguth @anburger @alopezso for awarnesshttps://gitlab.cern.ch/atlas/athena/-/merge_requests/51990Adding jFEX tau, jJ and jLJ thresholds2022-04-08T15:43:33+02:00Sergi Rodriguez BoscaAdding jFEX tau, jJ and jLJ thresholdsThis MR is meant to implement in the HLT seeding the threshold patterns for jTau, jJ and jLJ of L1Calo objects.
Also mentioned in JIRA ticket ATR-25308
Tagging also @khoo, @tamartin and @aranzazuThis MR is meant to implement in the HLT seeding the threshold patterns for jTau, jJ and jLJ of L1Calo objects.
Also mentioned in JIRA ticket ATR-25308
Tagging also @khoo, @tamartin and @aranzazuhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/51678ATLASRECTS-6926, ATR-25239, ATLASRECTS-6928: fixes for b-tagging2022-03-30T15:43:02+02:00Dan GuestATLASRECTS-6926, ATR-25239, ATLASRECTS-6928: fixes for b-tagging!51419 broke some things. I'm trying to fix them:
- ATLASRECTS-6926: Fix for config function that was renamed
- ATR-25239: remove online monitoring access to `MV2c10_discriminant`
- ATLASRECTS-6928: remove skimming strings that use `MV2c...!51419 broke some things. I'm trying to fix them:
- ATLASRECTS-6926: Fix for config function that was renamed
- ATR-25239: remove online monitoring access to `MV2c10_discriminant`
- ATLASRECTS-6928: remove skimming strings that use `MV2c10_discriminant`
This should close the above issues. It turns out it's also blocking some cleanup for the EDM (ATLASRECTS-6833) because MV2 asks for `SV1_p*`, which isn't ever set.
Tagging @duperrin @thuffmanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/51449FlavorTagDiscriminants: add scalar track pt sum to output2022-03-23T15:44:19+01:00Philipp GadowFlavorTagDiscriminants: add scalar track pt sum to outputThis MR adds an additional output variable as a decorator to the `BTagging` object.
The output variable is defined as the scalar sum of the track pt of the tracks associated to the jet.
It can be used e.g. for defining relative pt fract...This MR adds an additional output variable as a decorator to the `BTagging` object.
The output variable is defined as the scalar sum of the track pt of the tracks associated to the jet.
It can be used e.g. for defining relative pt fraction of tracks w.r.t. this quantity or for constructing an observable which can be used for flavour tagging algorithm training (see attached plot).
![image](/uploads/1eccba21f5eec536f292f24430724a54/image.png)
tagging @mguth @dguest @duperrin @thuffmanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/51419Cleanup btagging configuration2022-04-05T20:58:05+02:00Dan GuestCleanup btagging configurationThis consolidates the configuration functions we use in several places:
- [trigger](https://gitlab.cern.ch/atlas/athena/-/blob/master/Trigger/TriggerCommon/TriggerMenuMT/python/HLT/Bjet/BjetFlavourTaggingConfiguration.py),
- [reconstruc...This consolidates the configuration functions we use in several places:
- [trigger](https://gitlab.cern.ch/atlas/athena/-/blob/master/Trigger/TriggerCommon/TriggerMenuMT/python/HLT/Bjet/BjetFlavourTaggingConfiguration.py),
- [reconstruction](https://gitlab.cern.ch/atlas/athena/-/blob/master/PhysicsAnalysis/JetTagging/JetTagAlgs/BTagging/python/BTagRun3Config.py),
- [derivations](https://gitlab.cern.ch/atlas/athena/-/blob/master/PhysicsAnalysis/DerivationFramework/DerivationFrameworkFlavourTag/python/FtagRun3DerivationConfig.py), and
- [retagging](https://gitlab.cern.ch/atlas-flavor-tagging-tools/training-dataset-dumper/-/blob/r22/BTagTrainingPreprocessing/python/retag.py) (which doesn't happen in the Athena repo).
Overview
--------
Pictures are cool:
```mermaid
graph TD;
subgraph BTagAlgs [Configured by One Function]
assoc[JetParticleAssociation] --> jettag & finder
assocm[JetParticleAssociation muons] --> jettag
finder[JetSecVtxFinding] --> vx[JetSecVertexing]
vx --> jettag
jettag[JetBTagging] ==> muaug[BTagMuonAugmenter] & jetaug[BTagJetAugmenter]
muaug & jetaug ==> dl[Machine Learning Algorithms]
end
db[Calibration Database] --> jettag
tr(tracks) -.-> aug & vx & jetaug & dl
mu(Muons) -.-> assocm & muaug
aug[BTagTrackAugmenter] --> assoc
jet(jets) -.-> assoc & assocm & finder & vx & jettag
pv(Primary Vertex) -.-> finder & vx & jettag
json(List of NN Files) -.-> dl
dl ==> btag(BTagging Object)
```
This is a rough sketch of how information flows through the b-tagging code. Little boxes are algorithms, and the dotted lines indicate where some information needs to be passed into them. Solid lines indicate objects that are created internally. In the solid line case, the name of the object has to be synchronized between algorithms. The `BTagging` object follows the thick black line.
The key point here is that **this logic is implemented in 4 different places.**
The problem
-----------
Modular stuff is good. But in this case the 4 implementations are all supposed to do the same thing. The underlying code is also a bit crufty and some of the boxes should probably be split or merged, which is really hard to do in a few places coherently.
So for now it's probably better to merge everything. The big gray box holds the algorithms we configure with one function. **We want to put everything in the gray box!** Once we've done that we can move stuff around to make it easier to pop new boxes in and take old boxes out.
Implementation
--------------
The idea was to move everything into the box, but that turned out to be a bit more difficult. Instead most of the tagging calls three functions:
1. a calibration database setup,
1. track augmentation, and
1. the top level b-tagging one (the gray box).
I wasn't able to merge the first two into the last because:
- The conditions database setup function for derivations can't be replaced by `JetTagCalibCfg` for some reason. It seems to break the muon conditions alg when I try.
- Track augmentation has to be separated from the rest of tagging, because the retagging code uses a view container which is the union of two other containers. Both of these have to be augmented _before_ the containers are merged.
In the process of implementing this I made some other improvements:
- ATLASRECTS-6635: Some small progress on cleaning up `CompFactory` calls on imports
- ATLASRECTS-6172: Add soft muon scalars to the `BTagging` object
- Move configuration functions that call `FlavorTagDiscriminants` into `FlavorTagDiscriminants`
- Add or clean up some `ConfigFlags`:
- Merged `run2TaggersList` and `Run2TrigTaggers` into `taggerList`. They are the same taggers, but if they ever diverge the `ConfigFlags` aren't shared between reconstruction, trigger, and derivations anyway.
- Made the `taggerList` depend on whether we've enabled `RunFlipTaggers`
- Moved `calibrationChannelAliases` to `ConfigFlags`, cleaned it up considerably
- Added a `forcedCalibrationChannel` option, which tells every tagger to use a specific calibration channel
- Updated the "retagging" store gate renaming functions to be the ones we actually use for retagging
I also deleted and simplified a lot of unused code.
Validation
----------
This causes no changes in any physics outputs (I checked trigger and derivations). I've done some tests on `DAOD_PHYS` and `DAOD_FTAG1`. The only changes to FTAG1 (over a few hundred events) were the addition of `softMuon` variables.
Built on nightly `2022-03-21T2101`
Implications for developers
---------------------------
A few things have moved around, so I'll give a short guide on where to find them now. Everything that runs the main tagging chain will now have a call like
```python
BTagAlgsCfg(cfgFlags, JetCollection, nnList)
```
Which is defined in [BTagging/BTagRun3Config.py](https://gitlab.cern.ch/atlas/athena/-/blob/master/PhysicsAnalysis/JetTagging/JetTagAlgs/BTagging/python/BTagRun3Config.py). The `nnList` is a list of all dips and dl1 taggers for that specific collection. There are also optional arguments for the `trackCollection`, `muons`, and `primaryVertices` (by default they are the standard offline ones).
A lot more options have also been moved to [BTagging/BTaggingConfigFlags.py](https://gitlab.cern.ch/atlas/athena/-/blob/master/PhysicsAnalysis/JetTagging/JetTagAlgs/BTagging/python/BTaggingConfigFlags.py). These include `calibrationChannelAliases` and the `taggerList`, the later of which has a default that depends on whether the flip taggers are enabled.
To Do
-----
I left out a few things that should be discussed with the flavor tagging group, or that might depend on external developments:
- Figure out why I can't use the same calibration database setup function in derivations.
- Do track collection merging as part of this function.
- Consider using `forcedCalibrationChannel` in more places. We might have PFlow specific trainings for taggers that use the calibration database, and I'm pretty sure we don't have anything specific for variable radius track jets. If the trainings are all identical we could replace the channel aliases with an empty list and map everything to one jet collection.
- Enable muon information in reconstruction jobs. Right now the data dependencies for BTagMuonAugmenter aren't correct, which leads to random crashes in Athena MT. Derivations are single thread for now, so the muons still run there.
- Disable `MV2c10` in the trigger code. See ATR-25239.https://gitlab.cern.ch/atlas/athena/-/merge_requests/50536AthenaServices: Document MetaDataSvc2022-03-17T21:43:18+01:00Frank Berghausfrank.berghaus@cern.chAthenaServices: Document MetaDataSvcExamine and document the MetaDataSvc and its methods.
The formatting just comes from the vscode configuration in the repository.
Tag: @mnowak @amete @gemmerenExamine and document the MetaDataSvc and its methods.
The formatting just comes from the vscode configuration in the repository.
Tag: @mnowak @amete @gemmerenhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/50440fix for mTA being larger than jet energy2022-04-04T14:44:28+02:00Davide Melinifix for mTA being larger than jet energydevelopers of the CxAOD framework found a low-pT jet for which the track-assisted mass was larger than the jet energy.
This produce an error when re-computing the pT after the mass calibration. The problem was found for a jet not in the ...developers of the CxAOD framework found a low-pT jet for which the track-assisted mass was larger than the jet energy.
This produce an error when re-computing the pT after the mass calibration. The problem was found for a jet not in the recommended range of the calibration, but it is anyway good to add a fix to prevent this unwanted behaviour.
This MR adds a fix, setting mTA=0 when mTA>jet.E , common to other cases when the mTA is mis-calculated.
Tagging @camacho @mswiatlo @tpoulsen for JetEtmiss, @bmoser @hanar for CxAOD framework.https://gitlab.cern.ch/atlas/athena/-/merge_requests/50224Make JetSecVertexingAlg.cxx handle nullptr more properly. Instead of skipping...2022-02-10T21:43:10+01:00Bingxuan LiuMake JetSecVertexingAlg.cxx handle nullptr more properly. Instead of skipping the jets with no vertexices (nullptr), assigning default element linksNull pointer is assigned when there are no tacks associated with the jets in the Secondary Vertex and Jet Fitter algorithm. The element links are not set due to the failed cast on the nulls. When resetting the element links afterwards, t...Null pointer is assigned when there are no tacks associated with the jets in the Secondary Vertex and Jet Fitter algorithm. The element links are not set due to the failed cast on the nulls. When resetting the element links afterwards, this triggers errors.
The fix uses the handle's this case in a more proper way. It does not rely on cast any more to determine the algo. Instead it uses the algo name directly and checks whether it is null afterwards. In this way, even when there are no tracks associated with the jets, the default element link is created.https://gitlab.cern.ch/atlas/athena/-/merge_requests/49966FlavorTagDiscriminants: do not bail out in VRJetOverlapDecorator for events w...2023-04-18T10:27:16+02:00Philipp GadowFlavorTagDiscriminants: do not bail out in VRJetOverlapDecorator for events with less than 2 track jetsIn the VRJetOverlapDecorator, currently the jets are not decorated with the overlap information.
Although this is resourceful, it presents a problem for downstream analysis code which expects decorators to be present on every track jet.
...In the VRJetOverlapDecorator, currently the jets are not decorated with the overlap information.
Although this is resourceful, it presents a problem for downstream analysis code which expects decorators to be present on every track jet.
This MR removes a line causing to bail out of the code and consequently results in all track jets having the decorators attached.
tagging @dmascion @dguest @mguthhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/49175add VRJetOverlapDecorator variables to VR track jet output in DerivationFrame...2021-12-16T15:43:20+01:00Philipp Gadowadd VRJetOverlapDecorator variables to VR track jet output in DerivationFrameworkThe VR track jets used for b-tagging boosted objects have an ill-defined b-tagging calibration for event topologies with overlapping track jets.
The [FTAG recommendations for VR track jets](https://twiki.cern.ch/twiki/bin/view/AtlasProte...The VR track jets used for b-tagging boosted objects have an ill-defined b-tagging calibration for event topologies with overlapping track jets.
The [FTAG recommendations for VR track jets](https://twiki.cern.ch/twiki/bin/view/AtlasProtected/BTagCalibrationRecommendationsRelease21#Recommendations_for_variable_rad) suggest to veto events "if any of your signal jets have relativeDeltaRToVRJet < 1.0."
Currently, this variable is missing in the VR track jet output.
This MR schedules the [VRJetOverlapDecorator](https://gitlab.cern.ch/atlas/athena/-/tree/21.2/PhysicsAnalysis/JetTagging/FlavorTagDiscriminants#hbb-tagging)](https://gitlab.cern.ch/atlas/athena/-/tree/21.2/PhysicsAnalysis/JetTagging/FlavorTagDiscriminants#hbb-tagging) as a jet modifier when adding VR track jets to a derivation output and add its output to the list of VR track jet variables to be written out.https://gitlab.cern.ch/atlas/athena/-/merge_requests/48917Master flip tagger implementation sv2022-01-20T14:21:31+01:00Angela Maria BurgerMaster flip tagger implementation svImplementation of flip version of the SV-based b-taggers in Rel.22. This is necessary for the light jet mistag calibration in b-tagging.Implementation of flip version of the SV-based b-taggers in Rel.22. This is necessary for the light jet mistag calibration in b-tagging.Angela Maria BurgerAngela Maria Burgerhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/48563Move remaining DerivationFrameworkCalo code to handles for reading/writing fr...2021-11-29T21:42:44+01:00Giovanni MarchioriMove remaining DerivationFrameworkCalo code to handles for reading/writing from/to StoreGateUse ReadHandles and WriteHandles to read/write stuff in StoreGateUse ReadHandles and WriteHandles to read/write stuff in StoreGatehttps://gitlab.cern.ch/atlas/athena/-/merge_requests/48431changed ROC eff range for Zprime sample2021-11-23T15:42:59+01:00Binbin Dongchanged ROC eff range for Zprime samplestarting b-tagging efficiency from 0.1 in ROC for Zprime sample plotting
tagging: @vdao , @duperrin , @juhofer for awarenessstarting b-tagging efficiency from 0.1 in ROC for Zprime sample plotting
tagging: @vdao , @duperrin , @juhofer for awarenesshttps://gitlab.cern.ch/atlas/athena/-/merge_requests/47012BTagging+JetRecTools+JetSimTools: delete obsolete job options2021-10-09T19:05:26+02:00Frank WinklmeierBTagging+JetRecTools+JetSimTools: delete obsolete job optionsDelete job options that are not used, have not been updated in many years and are referencing code (e.g. CBNT) that
doesn't even exist anymore.Delete job options that are not used, have not been updated in many years and are referencing code (e.g. CBNT) that
doesn't even exist anymore.https://gitlab.cern.ch/atlas/athena/-/merge_requests/46909AnalysisTop: Add radiationhigh/low weights for new ttZ samples to jet flavor ...2021-10-07T09:51:11+02:00Thomas James StevensonAnalysisTop: Add radiationhigh/low weights for new ttZ samples to jet flavor plots codeANALYSISTO-1140 Adding the weights called " dyn= -1 muR=0.50000E+00 muF=0.50000E+00 " and " dyn= -1 muR=0.20000E+01 muF=0.20000E+01 " to the JetFlavorPlots code in AnalysisTop so that the radiationhigh/low options work for the new ttZ si...ANALYSISTO-1140 Adding the weights called " dyn= -1 muR=0.50000E+00 muF=0.50000E+00 " and " dyn= -1 muR=0.20000E+01 muF=0.20000E+01 " to the JetFlavorPlots code in AnalysisTop so that the radiationhigh/low options work for the new ttZ signals e.g. 504330.aMCPy8EG_NNPDF30NLO_A14N23LO_tteehttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45289Adding Jets to AOD in B-jet ART2021-07-21T03:02:40+02:00Christian NassAdding Jets to AOD in B-jet ARTRe-adding Jets to AOD produced in B-jet ART. This is needed, because b-tagging info is linked to jets.Re-adding Jets to AOD produced in B-jet ART. This is needed, because b-tagging info is linked to jets.https://gitlab.cern.ch/atlas/athena/-/merge_requests/45169Simplify Jet derivation framework2021-07-20T03:03:00+02:00William Keaton BalunasSimplify Jet derivation frameworkWith the recent change to reconstructing all jets at the derivation step, a large part of the jet derivation framework is now needlessly complicated. Most of this is designed around the "augmentation" workflow which reads in jets from th...With the recent change to reconstructing all jets at the derivation step, a large part of the jet derivation framework is now needlessly complicated. Most of this is designed around the "augmentation" workflow which reads in jets from the AOD, copies them, modifies/decorates the copy, and then copies decorations back to the original or overwrites it with the copy (e.g. by renaming).
There's no longer any need for this copying, or for any "updating" of existing jet quantities at derivation level: we can just make correct and up-to-date versions to begin with. The `IJetDecorator` interface and `JetDecorationAlg` make for much simpler scheduling of jet moments at the DAOD step.
So, this removes a large chunk of code which is now obsolete and migrates to the simpler way of doing this instead.
- Jet re-calibration at derivation level is no longer needed (we now instead use an up-to-date calibration to being with)
- JVT no longer needs to be updated at derivation level.
- b-tagging doesn't need to be "re-done", so some of the obsolete config for that has also been removed.
- Other jet moments (e.g. PFlow fJVT, QG tagging variables, etc.) are now scheduled via `JetDecorationAlg`.
Tagging @sawyer, @cdelitzs, @mswiatlo, @dguest, @duperrin.