athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2022-09-22T10:50:18+02:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/56788PFlow Updates to Run MET in Derivations2022-09-22T10:50:18+02:00Mark HodgkinsonPFlow Updates to Run MET in DerivationsThis adds configuration needed to create new decorations that MET reconstruction needs. Some updates are also done to the muon and tau FlowElement association tools to avoid crashes when running from AOD (a workflow not exercised until n...This adds configuration needed to create new decorations that MET reconstruction needs. Some updates are also done to the muon and tau FlowElement association tools to avoid crashes when running from AOD (a workflow not exercised until now).
The new MET reconstruction is available in this MR https://gitlab.cern.ch/atlas/athena/-/merge_requests/56622 for 22.0 and will then sweep to master. Once the latter happens MET reconstruction will crash in derivations without this MR, so ideally it would go in simultaneously.
Thanks,
Markhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/56622Add new links between global FE and CP Objects2022-09-16T16:26:25+02:00Mark HodgkinsonAdd new links between global FE and CP ObjectsThis MR fixes a bug in the MET reconstruction - currently for example it takes a link from an electron to FE and looks up the FE index. Then it assumes that index is valid in the global FE container - that assumption is invalid. The MR f...This MR fixes a bug in the MET reconstruction - currently for example it takes a link from an electron to FE and looks up the FE index. Then it assumes that index is valid in the global FE container - that assumption is invalid. The MR fixes this by creating new links between global FE and electron/photon/muon/taus and then updates the MET c++ code to use these links.
Configuration is added to remove these new global links, and associated variables, from the AOD/ESD - the global FE are not written to either ESD or AOD, so any associated decorations related to this would be useless.
This MR should not violate FT0V in that the AOD contents will not change. The ESD contents, which includes MET, will change because the MET output changes. Therefore eventually when this goes to master it is expected the MET content in PHYS and PHYSLite will change @jcatmore. Can you provide an example Reco_tf command I can use to check if any additional derivation specific config changes are required (this will be the case, if neither RecExCommon nor RecoSteering are used - we would find MET crashes when it does not find these new global links)? Given we don't run derivations in 22.0, I would propose to address this in a separate MR for master once this sweeps there.
Cheers,
Markhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/55667Fixes for TruthJet writing during Gen_tf.py jobs2022-08-11T15:18:53+02:00John Derek ChapmanFixes for TruthJet writing during Gen_tf.py jobsIt was observed that despite being created during generation jobs `xAOD::JetContainer` objects for Truth jets were not being written out to the EVNT file. After some debugging a number of issues were identified and are fixed in this merg...It was observed that despite being created during generation jobs `xAOD::JetContainer` objects for Truth jets were not being written out to the EVNT file. After some debugging a number of issues were identified and are fixed in this merge request.
Update syntax for adding Truth `xAOD::JetContainer` objects to `StreamEVGEN`.
Block loading dictionaries which are not present in `AthGeneration` or `AthSimulation` during `xAOD::JetContainer` writing.John Derek ChapmanJohn Derek Chapmanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/55606Draft: 21.22022-08-15T06:14:15+02:00Lianyou ShanDraft: 21.2Reconstruct taus on AOD and identify with RNN during producing derivation, only in R21.2, with possible muon overlap removed. Mainly DiTauRec, DerivationFrameworkTau.Reconstruct taus on AOD and identify with RNN during producing derivation, only in R21.2, with possible muon overlap removed. Mainly DiTauRec, DerivationFrameworkTau.Lianyou ShanLianyou Shanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/53648Switch to GSF by default for electron chains inside the TrigEgammaMatchingTool2022-05-25T17:16:50+02:00Edmar Egidio Purcino De SouzaSwitch to GSF by default for electron chains inside the TrigEgammaMatchingToolThis MR is to fix the electron keys inside the TrigEgammaMatchingTool, setting the GSF key as default for electrons.
This discussion is being done in ATR-25223 .
ping: @cjmeyer , @jodafons , @safarzad , @fernando and @jlieberm .This MR is to fix the electron keys inside the TrigEgammaMatchingTool, setting the GSF key as default for electrons.
This discussion is being done in ATR-25223 .
ping: @cjmeyer , @jodafons , @safarzad , @fernando and @jlieberm .Edmar Egidio Purcino De SouzaEdmar Egidio Purcino De Souzahttps://gitlab.cern.ch/atlas/athena/-/merge_requests/53420Use GetClassification instead of GetResponse (MVAUtils) for Tau Trigger FTF BDT2022-05-18T18:09:33+02:00Bertrand Martin Dit LatourUse GetClassification instead of GetResponse (MVAUtils) for Tau Trigger FTF BDTHello,
Basically, a resubmission of !53340 (already reviewed and approved) due to merge conflicts.
This MR is fixing a regression-vs-classification misconfiguration of a BDT classifier used in tau triggers.
Currently, we evaluate a BDT...Hello,
Basically, a resubmission of !53340 (already reviewed and approved) due to merge conflicts.
This MR is fixing a regression-vs-classification misconfiguration of a BDT classifier used in tau triggers.
Currently, we evaluate a BDT classifier in "regression mode", with the GetResponse function of MVAUtils being called.
However, for a classifier, this returns BDT scores that are not within the usual [0,1] range.
And this leads to buggy behaviour in TrigTauTrackRoiUpdater, where we intend to select the track with the highest BDT score, but we assume the BDT score is always positive (BDTMax variable initialised to 0).
As a consequence, unless we are lucky to get a track with a BDT score above 0 in the tauCore ROI of the Fast Track Finder, we fail to update the ROI for the tauIso step.
In particular, the zedMinus and zedPlus of the tauIso ROI are not set to +/-7 mm, but we rather inherit the settings from the tauCore ROI, i.e. we scan again along the whole z axis in the tauIso step, which must waste CPU.
This MR is changing the behaviour to "classification mode", which takes the sigmoid of GetResponse and ensures the output is within [0,1].
The reference file is updated with fixed trigger counts.
A BDT helper method was added to tauRecTools. As the other such methods, all it does is sort the variables in the expected order as defined in the input ROOT file.
Tagging @iriu , @adsalvad , @gipezzul , @ademaria .
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/53340Use GetClassification instead of GetResponse (MVAUtils) for Tau Trigger FTF BDT2022-05-20T12:27:10+02:00Bertrand Martin Dit LatourUse GetClassification instead of GetResponse (MVAUtils) for Tau Trigger FTF BDTHello,
This MR is fixing a regression-vs-classification misconfiguration of a BDT classifier used in tau triggers.
Currently, we evaluate a BDT classifier in "regression mode", with the GetResponse function of MVAUtils being called.
How...Hello,
This MR is fixing a regression-vs-classification misconfiguration of a BDT classifier used in tau triggers.
Currently, we evaluate a BDT classifier in "regression mode", with the GetResponse function of MVAUtils being called.
However, for a classifier, this returns BDT scores that are not within the usual [0,1] range.
And this leads to buggy behaviour in TrigTauTrackRoiUpdater, where we intend to select the track with the highest BDT score, but we assume the BDT score is always positive (BDTMax variable initialised to 0).
As a consequence, unless we are lucky to get a track with a BDT score above 0 in the tauCore ROI of the Fast Track Finder, we fail to update the ROI for the tauIso step.
In particular, the zedMinus and zedPlus of the tauIso ROI are not set to +/-7 mm, but we rather inherit the settings from the tauCore ROI, i.e. we scan again along the whole z axis in the tauIso step, which must waste CPU.
This MR is changing the behaviour to "classification mode", which takes the sigmoid of GetResponse and ensures the output is within [0,1].
The reference file is updated with fixed trigger counts.
A BDT helper method was added to tauRecTools. As the other such methods, all it does is sort the variables in the expected order as defined in the input ROOT file.
Tagging @iriu , @adsalvad , @gipezzul , @ademaria .
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/53294ctau seeding2022-06-02T14:49:23+02:00Nicola Orlandonicola.orlando@cern.chctau seedingImplementation of ctau HLT seeding based on L1Topo ctau multiplicity class.
The implementation is just a draft, need to check
- Granularity of the used coordinates and pTs
- Is overall this as expected for HLT? @rbielski
#ATR-25307, r...Implementation of ctau HLT seeding based on L1Topo ctau multiplicity class.
The implementation is just a draft, need to check
- Granularity of the used coordinates and pTs
- Is overall this as expected for HLT? @rbielski
#ATR-25307, related to open issue here ATR-25462 (isolation cut is currently hard coded in the L1Topo sim)
@asonay @paulama @iriu @jmharrishttps://gitlab.cern.ch/atlas/athena/-/merge_requests/48213EDM update with the real position of the Trigger objects2021-11-16T12:22:07+01:00Sergi Rodriguez BoscaEDM update with the real position of the Trigger objectsThis MR is meant to set and save the real position of the different Trigger object sent to L1Topo. As well as a tiny modification in the forward jJ algorithm is done to be bitwise correct.
This MR should also include back the FWD jets.
...This MR is meant to set and save the real position of the different Trigger object sent to L1Topo. As well as a tiny modification in the forward jJ algorithm is done to be bitwise correct.
This MR should also include back the FWD jets.
Tagging Nicola (@orlando) since this should not affect the L1Topo for the central region.https://gitlab.cern.ch/atlas/athena/-/merge_requests/47285using L1 ROIs as reference to check clusters outside the ROI2021-10-28T16:06:20+02:00Antonio De Mariausing L1 ROIs as reference to check clusters outside the ROIThis MR will introduce the usage of the L1 ROIs to determine if a cluster if within the ROI or not -> this will be executed only at the Tau Calo reconstruction level, not in Preselection or Precision stage
Previously the ROI coming fro...This MR will introduce the usage of the L1 ROIs to determine if a cluster if within the ROI or not -> this will be executed only at the Tau Calo reconstruction level, not in Preselection or Precision stage
Previously the ROI coming from the TauCaloROIUpdater was used, but this ROI was already updated after the check of the cluster withing ROI or not -> so if we use this ROI we can have a bias because we need to mimic exactly the same procedure in TauCaloROIUpdater and TrigTauRec
So to do exactly the same type of operation in the TauCaloROIUpdater and in TrigTauRec, we need to use the L1 ROIs in both cases
tagging also @martindlhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/46886Manual sweep of SystematicsSvc improvements from master2021-10-04T10:50:45+02:00Tadej Novaktadej.novak@cern.chManual sweep of SystematicsSvc improvements from masterThis is a manual sweep of many MRs from ~master. No fixes are done (only syntax changes). The changes got a bit messy in the process, so marking to be squashed.
- atlas/athena!44986
- atlas/athena!45184
- atlas/athena!45825
Also includ...This is a manual sweep of many MRs from ~master. No fixes are done (only syntax changes). The changes got a bit messy in the process, so marking to be squashed.
- atlas/athena!44986
- atlas/athena!45184
- atlas/athena!45825
Also including atlas/Athena!39398 to ease sweeping in the future.
@krumnack, please try to have a quick look that I did not mess-up something.
I'll prepare some fixes in parallel for transparency. We should coordinate that all connected MRs would go in before a new release will be built.
FYI @jburr @mmuskinj @lheinrichttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45370tauRecTools: deploy R22 track classifier2021-07-22T20:06:00+02:00Bertrand Martin Dit LatourtauRecTools: deploy R22 track classifierHello,
This MR is deploying the RNN tau track classifier tune for the R22 reprocessing.
It was derived on Round 2.5 MC preproduction (ATLTAU-1738).
There are minor changes in variable definitions or names compared to the previous tune (...Hello,
This MR is deploying the RNN tau track classifier tune for the R22 reprocessing.
It was derived on Round 2.5 MC preproduction (ATLTAU-1738).
There are minor changes in variable definitions or names compared to the previous tune (Round 1.5).
We are still scrutinising some trainings that are just becoming available, so this json file is a baseline, which we might want to update in the next hour if a newer one if found to be better.
Adding the urgent flag as we will need this for the R22 reprocessing.
Tagging @eszaid , @ghamity , @avishwak , @qbuat for information.
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45304tauRecTools: enable cells for 0-prong taus and update 0p MVA TES (try3)2021-07-20T13:35:35+02:00Bertrand Martin Dit LatourtauRecTools: enable cells for 0-prong taus and update 0p MVA TES (try3)Hello,
This MR is the 3rd resubmission of the same MR (!45290 , !45294 ) where we saw random count variations in the digest due to concurrent muon MRs.
Sorry if 3 identical MRs makes no sense, but I don't understand how the CI and diges...Hello,
This MR is the 3rd resubmission of the same MR (!45290 , !45294 ) where we saw random count variations in the digest due to concurrent muon MRs.
Sorry if 3 identical MRs makes no sense, but I don't understand how the CI and digest work. At least this time I did not get fake muon changes, so it should work fine :-)
Original description pasted below.
This MR is hopefully the last big MR for taus for the R22 reprocessing! It implements two features.
First, it is revising the input variables used for the MVA Tau Energy Scale calibration for 0-prong taus.
The new variables improve slightly the resolution.
Also, true 3-prong taus reconstructed as 0p were given increased weight in the BRT training, as the resolution for 3p is natively quite bad with this calo-only energy calibration.
Second, it enables the pi0 and photon shot reconstruction for 0p taus. So far, the reconstruction of these tau constituents was limited to 1-5 prong, because tau substructure reconstruction is not run for 0p nor >5p.
However, we anticipate to rerun a dedicated LLP->tau reconstruction with Large Radius Tracks on AODs (ATLTAU-1754).
Therefore we need to build pi0s and shots in the RAWtoESD step, and save the associated cells in the AOD, to make substructure reconstruction possible for 0p at AOD level (ATLTAU-1770).
In order to limit the AOD size increase to ~5 kb/event (ATLASRECTS-6505), the tau pt cut applied to 0p taus when writing to AOD was raised from 7.5 to 9 GeV.
To save more space, tau tracks for 0p candidates are also no longer written to disk, and will have to be re-associated (together with LRTs) and re-classified in the dedicated LLP reconstruction. Edit: this was actually not done because it was causing trouble downstream (monitoring).
I have verified that if doPi0andShots has the old behaviour (true for 1-5 prong, false otherwise), the tau reconstruction is unchanged (when ignoring TES + thinning cut changes), in particular the neutral PFO correction is identical.
Pi0s and shots are built for 0p, but are not used in the substructure reconstruction, where 0p are basically still ignored.
This is why I moved the vertex correction of neutral PFOs from TauPi0ClusterScaler (still run only for 1-5p, not 0p) to TauPi0ClusterCreator (now called for 0-5p, anyway a much better place to do that), so that the 0p neutral PF0s are properly corrected.
Adding the 'urgent' flag as we'd like to have this for the R22 reprocessing.
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45294tauRecTools: enable cells for 0-prong taus and update 0p MVA TES (resubmit)2021-07-20T11:55:04+02:00Bertrand Martin Dit LatourtauRecTools: enable cells for 0-prong taus and update 0p MVA TES (resubmit)Hello,
This MR is basically a resubmission of !45290 where we saw strange count variations related to muons in the digest.
I made a new MR from scratch, it is still there, so this MR is probably not needed but I submit it to be on the s...Hello,
This MR is basically a resubmission of !45290 where we saw strange count variations related to muons in the digest.
I made a new MR from scratch, it is still there, so this MR is probably not needed but I submit it to be on the safe side.
Original description pasted below.
This MR is hopefully the last big MR for taus for the R22 reprocessing! It implements two features.
First, it is revising the input variables used for the MVA Tau Energy Scale calibration for 0-prong taus.
The new variables improve slightly the resolution.
Also, true 3-prong taus reconstructed as 0p were given increased weight in the BRT training, as the resolution for 3p is natively quite bad with this calo-only energy calibration.
Second, it enables the pi0 and photon shot reconstruction for 0p taus. So far, the reconstruction of these tau constituents was limited to 1-5 prong, because tau substructure reconstruction is not run for 0p nor >5p.
However, we anticipate to rerun a dedicated LLP->tau reconstruction with Large Radius Tracks on AODs (ATLTAU-1754).
Therefore we need to build pi0s and shots in the RAWtoESD step, and save the associated cells in the AOD, to make substructure reconstruction possible for 0p at AOD level (ATLTAU-1770).
In order to limit the AOD size increase to ~5 kb/event (ATLASRECTS-6505), the tau pt cut applied to 0p taus when writing to AOD was raised from 7.5 to 9 GeV.
To save more space, tau tracks for 0p candidates are also no longer written to disk, and will have to be re-associated (together with LRTs) and re-classified in the dedicated LLP reconstruction.
I have verified that if doPi0andShots has the old behaviour (true for 1-5 prong, false otherwise), the tau reconstruction is unchanged (when ignoring TES + thinning cut changes), in particular the neutral PFO correction is identical.
Pi0s and shots are built for 0p, but are not used in the substructure reconstruction, where 0p are basically still ignored.
This is why I moved the vertex correction of neutral PFOs from TauPi0ClusterScaler (still run only for 1-5p, not 0p) to TauPi0ClusterCreator (now called for 0-5p, anyway a much better place to do that), so that the 0p neutral PF0s are properly corrected.
Adding the 'urgent' flag as we'd like to have this for the R22 reprocessing.
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/45274tauRecTools: slight improvement for 0p TES2021-07-19T12:41:02+02:00Bertrand Martin Dit LatourtauRecTools: slight improvement for 0p TESHello,
This MR is revising the input variables used for the MVA Tau Energy Scale calibration for 0-prong taus.
The new variables improve slightly the resolution.
Also, true 3-prong taus reconstructed as 0p were given increased weight in...Hello,
This MR is revising the input variables used for the MVA Tau Energy Scale calibration for 0-prong taus.
The new variables improve slightly the resolution.
Also, true 3-prong taus reconstructed as 0p were given increased weight in the training, as the resolution for 3p is natively quite bad with this calo-only BRT.
The gain is modest, but always welcome.
Adding the 'urgent' flag as we'd like to have this for the R22 reprocessing.
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/41237Fix the Tau second stage Roi sizes2021-03-06T21:28:48+01:00Mark SuttonFix the Tau second stage Roi sizesThe second stage tau Roi is intended to be wider than the first stage Tau Roi,
this adds configurable parameters to allow the second stage Roi size to be
adjusted.
At present, the second stage tau Roi takes it eta and phi widths from th...The second stage tau Roi is intended to be wider than the first stage Tau Roi,
this adds configurable parameters to allow the second stage Roi size to be
adjusted.
At present, the second stage tau Roi takes it eta and phi widths from the first stage Roi, but tightens the Roi in z at the beamline, and is thus a strict subset of the first stage Roi meaning the second stage tracking would not be needed at all. This increases the Roi eta-phi width for the second stage taus.
As a result of increasing the second stage Roi width, the tau counts will likely change. These will be updated once the CI tests have executed.https://gitlab.cern.ch/atlas/athena/-/merge_requests/37525xAODTau: add a lightweight EDM, TauCluster2020-11-05T10:48:43+01:00Xiaozhong HuangxAODTau: add a lightweight EDM, TauClusterAdd TauCluster, which contains the four momentum pointing at the tau
vertex, dR w.r.t the tau axix, and an ElementLink to the original
CaloCluster used in jet reconstrution. The original link to the CaloCluster
is removed since it is not...Add TauCluster, which contains the four momentum pointing at the tau
vertex, dR w.r.t the tau axix, and an ElementLink to the original
CaloCluster used in jet reconstrution. The original link to the CaloCluster
is removed since it is not used at all.
After this MR is merged, we could associate the TauCluster to the
tau candidate, so that we do not need to obtain the clusters from
scratch and perform the vertex correction every time !https://gitlab.cern.ch/atlas/athena/-/merge_requests/2861821.2: Redefining HggPrimaryVertices in HIGG12019-12-11T15:10:19+01:00Ioannis Nomidis21.2: Redefining HggPrimaryVertices in HIGG1Changes to HggPrimaryVertices, the vertex collection used in H->yy analyses.
Changes to it are required to allow developments in the HIGG1D1 derivations needed for PFlow: https://its.cern.ch/jira/browse/HGAMSW-716
In specific, the new co...Changes to HggPrimaryVertices, the vertex collection used in H->yy analyses.
Changes to it are required to allow developments in the HIGG1D1 derivations needed for PFlow: https://its.cern.ch/jira/browse/HGAMSW-716
In specific, the new container is now a shallow copy of PrimaryVertices with redefined vertexType so that the primary vertex is the one selected by the PhotonVertexSelection tool. Decorations are also added to maintain previous functionality.
These changes are also be backwards compatible: the name and format of the container is the same, the only practical difference is that the new container contains also pile-up vertices (because it is a shallow copy of PrimaryVertices).
Code has been tested in 21.2.84.0.https://gitlab.cern.ch/atlas/athena/-/merge_requests/27784WIP Addition of Tau Fake Factor Tool2020-03-23T18:59:48+01:00Joseph M MuseWIP Addition of Tau Fake Factor ToolTwo packages have been added to /PhysicsAnalysis/TauID: TauFakeFactorTool and TauFakeFactorToolData. These are independent packages for two independent methods of estimating fake tau backgrounds. The packages are essentially stand-alone ...Two packages have been added to /PhysicsAnalysis/TauID: TauFakeFactorTool and TauFakeFactorToolData. These are independent packages for two independent methods of estimating fake tau backgrounds. The packages are essentially stand-alone executables with ROOT dependencies.
Both packages were tested as sparse builds in runtime environments: asetup 21.2,AthAnalysis,latest and asetup 21.2,AnalysisBase,latest
In both cases, the packages compiled and were executable with expected results.https://gitlab.cern.ch/atlas/athena/-/merge_requests/70047More test chains for delayed jets2024-03-22T13:20:55+01:00Lucas BezioMore test chains for delayed jetsAs discussed on [ATR-28836](https://its.cern.ch/jira/browse/ATR-28836), more test chains are added. Some are requiring 2jets to be delayed aiming to reduce the rate even with low pt threshold. Copies of the test chains with upper limit o...As discussed on [ATR-28836](https://its.cern.ch/jira/browse/ATR-28836), more test chains are added. Some are requiring 2jets to be delayed aiming to reduce the rate even with low pt threshold. Copies of the test chains with upper limit on timing are also added.