athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2024-03-28T13:34:35+01:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/69513Use config flags in analysis config2024-03-28T13:34:35+01:00Tadej Novaktadej.novak@cern.chUse config flags in analysis configMake config flags the main way to steer analysis config. This will help people working on analysis and Athena to feel at home and prevent accumulation of arguments of the `ConfigAccumulator`.
The naming is not fixed, I will probably als...Make config flags the main way to steer analysis config. This will help people working on analysis and Athena to feel at home and prevent accumulation of arguments of the `ConfigAccumulator`.
The naming is not fixed, I will probably also convert more items to flags. This is mainly to start the discussion and freeze the API as soon asp possible. I will probably then break this into multiple MRs.
Also some core flags should be renamed (see https://its.cern.ch/jira/browse/ATEAM-964).
Tagging @krumnack, @jolamber, @gwatts, @ekourlit for core AMG. Also tagging interested parties @ravinab, @omajersk, @tstreble, @khoo, @jchapman.https://gitlab.cern.ch/atlas/athena/-/merge_requests/69576Fix zero eTau rates when using eTau BDT algorithm2024-03-11T15:52:53+01:00Ralf Gugelralf.gugel@cern.chFix zero eTau rates when using eTau BDT algorithmSwitching L1Topo sim to use more generic accessor for eTau quality flags introduced during eTau BDT development in order to make the L1Topo simulation agnostic to what flavor of algorithm was used on the eFEX side.
Relevant Jira: ATR-28835Switching L1Topo sim to use more generic accessor for eTau quality flags introduced during eTau BDT development in order to make the L1Topo simulation agnostic to what flavor of algorithm was used on the eFEX side.
Relevant Jira: ATR-28835https://gitlab.cern.ch/atlas/athena/-/merge_requests/68328TauAnalysisTools: Use data handles in BuildTruthTaus2024-03-13T16:16:30+01:00Bertrand Martin Dit LatourTauAnalysisTools: Use data handles in BuildTruthTausHello,
The main goal of this MR is to replace direct access from evtStore with read/write handles, to allow derivations to run in MT (ATLASG-2528). This is located in `BuildTruthTaus`. I dropped a few deprecated functionalities, in part...Hello,
The main goal of this MR is to replace direct access from evtStore with read/write handles, to allow derivations to run in MT (ATLASG-2528). This is located in `BuildTruthTaus`. I dropped a few deprecated functionalities, in particular `WriteTruthTaus=0` which was building truth taus and keeping them in memory without registering them to SG. I also changed the behaviour of truth tau building. Before, if `TruthTaus` were not present in the input file, `BuildTruthTaus` would trigger truth tau building from `TruthParticles`. Now, `BuildTruthTaus` will always run truth tau building, unless it is put in "truth matching mode" by the TauTruthMatchingTool, in which case it will read the existing `TruthTaus` and apply truth matching to reconstructed TauJets.
This is a first step, the BuildTruthTaus+TauTruthMatchingTool design is still somewhat unfriendly and should be further improved.
The MR was tested on 1000 TRUTH3 events and 500 PHYS events, it doesn't change the output.
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/66657TrigTauRec: drop deprecated config flag2023-10-24T21:42:07+02:00Bertrand Martin Dit LatourTrigTauRec: drop deprecated config flagHello,
This MR is removing a couple of config flags that are no longer used in HLT tau reconstruction (deprecated Tau Energy Scale calibration, and tune of the BDT used in tracktwoMVABDT chains now decommissioned).
Cheers,
BertrandHello,
This MR is removing a couple of config flags that are no longer used in HLT tau reconstruction (deprecated Tau Energy Scale calibration, and tune of the BDT used in tracktwoMVABDT chains now decommissioned).
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/65087Cross-link nominal and systematic variations objects to build union containers2023-08-23T20:11:58+02:00Teng Jian KhooCross-link nominal and systematic variations objects to build union containersThis is an alternative approach to `CP::AsgUnionSelectionAlg`, which flags all objects in a container with its systematic variations for which any variation passes some selection criteria. The concept is that:
- At some point when we sti...This is an alternative approach to `CP::AsgUnionSelectionAlg`, which flags all objects in a container with its systematic variations for which any variation passes some selection criteria. The concept is that:
- At some point when we still have access to an unfiltered container, we apply the SystObjectLinkerAlg. It should happen when all systematic variations affecting this container are already known. This applies two sets of decorations, as follows:
- Each object in the nominal container receives a `systLinkVar_%SYS%` decoration for every variation.
- Each object in a variation container receives a `nominalObjectLink` decoration.
- Downstream of this, the user applies some selection, building `VIEW_ELEMENTS` containers that pass their analysis selection. In event selection algorithms and observable computations, they need only loop over the objects in these filtered containers. This filtering should be done in a systematics-aware way preserving the usual `ContainerName_%SYS%` convention (e.g. with `SysWriteHandles`).
- Before writing to an output file, the corresponding `CP::Syst[Object]UnioniserAlg` is run on the filtered container. It builds a set containing all selected nominal objects, and then adds to this any other systematic variation objects that were not already selected. This forms the union of all selected objects. It then loops over the nominal union set, recording this to a new `VIEW_ELEMENTS` container and uses the links to populate corresponding variation output containers.
It is important that the linker runs early on, hence I have put it in the `makeBlahAnalysisSequences` functions with the option to toggle it on. If we run this on prefiltered selections we can run into this issue:
```
ENTRY | TAU | NOSYS | TAUS_TRUEHADTAU_SME_TES_INSITUFIT__1down | TAUS_TRUEHADTAU_SME_TES_INSITUFIT__1up
------------------------------------------------------------
0 | 0 | 126 | 126 | 126
1 | 0 | 60.1 | -- | 60.3
2 | 0 | 69.4 | 69.4 | 69.4
```
One variation in the 2nd event has no selected object (pt is 59.9 GeV with a cut at 60 GeV), so we are unable ever to access it. While we can go from a non-empty filtered collection back to the full one, nothing can be done about an empty collection.
Another caveat: It is possible to cause objects to depend on more systematic variations than existed at the time that the calibration sequences ran. In this case, one needs to defer the selection from the existing sequence and run the linker when these correlations are known. We might also need a modified procedure to handle something like overlap removal, which doesn't multiply the object copies, but does generate extra containers for systematics that were not initially affecting the input containers.
For a more explicit statement of the motivation thanks to @gwilliam:
> We want to be able to write out just the sys varied pt for an object so we need to take the union of nominal + sys variations to avoid getting out of sync with the other variables e.g. eta. Now, this can be done with selection flags following the examples but this is a bit of a pain if one also wants to do event selection / filtering on these as you have to pass around not only the container but also the selection.
> For example, in the bbtautau case we were thinking of applying a loose preselection that requires 1 e/mu and 1 tau or 2 taus + 2 bjets. We would do this for nominal + each syst and keep events in the ntuple that pass at least one, labelling with an event flag in the ntuple which they passed. As part of this we also have to calculate the tautau mass based on the MMC to which we also need to pass the containers.
> It seems this would be easier for particularly new grad students to understand if we could just apply the selections as normal and then when writing deal with taking the union behind the scenes rather than keeping track of selection flags everywhere
TODO:
- [x] Implement in the ConfigBlock version of the CP algs as well
**Implementation details**
I had to template the `SystObjectUnioniserAlg`. Originally I intended to work with `IParticleContainer` only, but this is incompatible with `AsgxAODNTupleMakerAlg` because `IParticleContainer` does not provide a collection proxy -- only the derived containers do. Two template parameters are needed, one for the object type and one for the container type. The latter is explicitly needed because `DataVector<xAOD::Blah_v1>` does not have a classID -- only its versionless typedef `BlahContainer` does. The templated algs are then subclassed for the types that were obviously necessary, because otherwise `genConf` generates a long explicit name for the python class, even if one makes a compact typedef.https://gitlab.cern.ch/atlas/athena/-/merge_requests/63900Add HepMC::HERWIG7INTERMEDIATESTATUS constant2023-06-26T18:00:25+02:00Andrii VerbytskyiAdd HepMC::HERWIG7INTERMEDIATESTATUS constantAdd HepMC::HERWIG7INTERMEDIATESTATUS constant
https://gitlab.cern.ch/atlas/athena/-/merge_requests/63785
Tag @martindl @jchapmanAdd HepMC::HERWIG7INTERMEDIATESTATUS constant
https://gitlab.cern.ch/atlas/athena/-/merge_requests/63785
Tag @martindl @jchapmanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/60253TriggerMenuMT: pass flags to MenuSequence[CA]2023-02-02T21:44:10+01:00Frank WinklmeierTriggerMenuMT: pass flags to MenuSequence[CA]Explicitly pass the ConfigFlags to `MenuSequence` and `MenuSequenceCA`.
Only the latter would be strictly required but the former is useful to
make progress in eliminating the use of the global `ConfigFlags`.
Relates to ATR-24994 and re...Explicitly pass the ConfigFlags to `MenuSequence` and `MenuSequenceCA`.
Only the latter would be strictly required but the former is useful to
make progress in eliminating the use of the global `ConfigFlags`.
Relates to ATR-24994 and requires https://gitlab.cern.ch/atlas/athena/-/merge_requests/60252.
cc @fpastorehttps://gitlab.cern.ch/atlas/athena/-/merge_requests/60248Remove hardcoded tau isolation from L1Topo2023-02-01T21:44:20+01:00Paula Martinez SuarezRemove hardcoded tau isolation from L1TopoRead tau isolation WPs from L1Menu. <br>
Update for L1TopoSmulation and HLTSeeding. <br>
Local test does not show any change in trigger counts.
Tagging @asonay and @rbielski for double-check.Read tau isolation WPs from L1Menu. <br>
Update for L1TopoSmulation and HLTSeeding. <br>
Local test does not show any change in trigger counts.
Tagging @asonay and @rbielski for double-check.https://gitlab.cern.ch/atlas/athena/-/merge_requests/58175PanTau: fix constness, and add ATLAS_CHECK_THREAD_SAFETY2022-11-08T15:43:17+01:00Bertrand Martin Dit LatourPanTau: fix constness, and add ATLAS_CHECK_THREAD_SAFETYHello,
This MR is getting rid of the last const_cast occurrences in PanTau. The main changes are:
* We pass the non-const neutral PFO container (created in tauRec) as an argument to the PanTau tools, such that we can access directly the...Hello,
This MR is getting rid of the last const_cast occurrences in PanTau. The main changes are:
* We pass the non-const neutral PFO container (created in tauRec) as an argument to the PanTau tools, such that we can access directly the non-const neutral PFOs.
* What we don't need to modify is made const, like the PFO* used to build the TauConstituent objects.
* If we find input neutral PFOs that have non-zero mass, we abort with an error. This could happen in a re-reconstruction from AOD, where the mass has been set in RAWtoALL before. In R21, we would allow such a configuration and reset the mass to 0. In R22, we would anyway have to rebuild the PFOs before calling PanTau, and therefore we don't expect to find a non-zero mass as input.
Tested locally with RAWtoALL on 200 events. Fortunately, it doesn't seem to change the reconstruction output...
Fixes ATLASRECTS-7307.
I hope the next step will be to finally turn TauRunnerAlg from `AthAlgorithm` to `AthReentrantAlgorithm` in tauRec!
Cheers,
Bertrandhttps://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/45430Refactored functions for memoization2021-09-15T12:04:27+02:00Kacper Wojciech TopolnickiRefactored functions for memoizationFunctions from -generateTau.py- were written as
a combination of two functions, one of which can
be momoized using the -AccumulatorCache- decorator.
@tbold @rbielski ATR-23200Functions from -generateTau.py- were written as
a combination of two functions, one of which can
be momoized using the -AccumulatorCache- decorator.
@tbold @rbielski ATR-23200https://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.https://gitlab.cern.ch/atlas/athena/-/merge_requests/30784Trigger: Fix unchecked StatusCodes2020-03-04T03:02:33+01:00Frank WinklmeierTrigger: Fix unchecked StatusCodes* Fix unchecked StatusCodes
* Delete obsolete TrigTileMonAlg* Fix unchecked StatusCodes
* Delete obsolete TrigTileMonAlghttps://gitlab.cern.ch/atlas/athena/-/merge_requests/70153Restored 2016MC15C MMC CalibSet for validation2024-03-27T17:55:12+01:00Thomas StreblerRestored 2016MC15C MMC CalibSet for validationFollow up to !65640
Restore 2016MC15C tuning as 2019 tuning seems to have some unexpected effect in bbtautau analysis (see slide 4 https://indico.cern.ch/event/1397000/contributions/5871927/attachments/2825319/4935154/20240322_HbbHtauta...Follow up to !65640
Restore 2016MC15C tuning as 2019 tuning seems to have some unexpected effect in bbtautau analysis (see slide 4 https://indico.cern.ch/event/1397000/contributions/5871927/attachments/2825319/4935154/20240322_HbbHtautau_FrameworkMeeting.pdf )
Will be used for validation purposes
FYI @ademaria @jdegens @bmoser @pbokanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69830Trigger: fix flake8 configuration2024-03-18T07:55:54+01:00Frank WinklmeierTrigger: fix flake8 configurationTo enable a disabled flake8 extension (e.g. `ALT900`) one has to use `--extend-extensions` not `--extend-select`. This meant that these checks were never running. Also fix the resulting warnings.
Relates to ATR-28970.To enable a disabled flake8 extension (e.g. `ALT900`) one has to use `--extend-extensions` not `--extend-select`. This meant that these checks were never running. Also fix the resulting warnings.
Relates to ATR-28970.https://gitlab.cern.ch/atlas/athena/-/merge_requests/69698Improve monitoring of non truth matched hadronic tau in TauCP PhysVal mon2024-03-13T12:00:22+01:00Antonio De MariaImprove monitoring of non truth matched hadronic tau in TauCP PhysVal monAdded following objects to the monitoring histograms:
* truth matched tau matched with an electron
* truth matched tau matched with a jet
Also switch to monitor correct eVeto flattened score
Tagging @martindl and @veellajoAdded following objects to the monitoring histograms:
* truth matched tau matched with an electron
* truth matched tau matched with a jet
Also switch to monitor correct eVeto flattened score
Tagging @martindl and @veellajohttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69697TauAnalysisTools and DFTau: introduce read/write decor handles for derivation...2024-03-12T11:19:51+01:00Bertrand Martin Dit LatourTauAnalysisTools and DFTau: introduce read/write decor handles for derivations in MTHello,
This MR is replacing accessors/decorators with Read/WriteDecorHandles in TauAnalysisTools and DerivationFrameworkTau, which will be necessary to run derivations in MT. This addresses an issue seen when running DAODs in MT (ATLASG...Hello,
This MR is replacing accessors/decorators with Read/WriteDecorHandles in TauAnalysisTools and DerivationFrameworkTau, which will be necessary to run derivations in MT. This addresses an issue seen when running DAODs in MT (ATLASG-2470):
```
08:03:01 ToolSvc.TauSelectorLoose 15 0 WARNING SG::ExcBadAuxVar: Attempt to retrieve nonexistent aux data item `::EleRNNLoose_v1' (946).
```
where a TauSelectionTool was trying to read a decoration before it was created by TauIDDecoratorWrapper.
The downside is that now, a tau container name must be declared in TauSelectionTool, while before, any TauJet object could be passed regardless of the tau container it came from (but now we can't avoid that).
Tagging @ademaria .
Cheers,
Bertrandhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69340Draft: TriggerMenuMT: centralize AccumulatorCache for steps and disable deepcopy2024-03-13T12:03:59+01:00Frank WinklmeierDraft: TriggerMenuMT: centralize AccumulatorCache for steps and disable deepcopyThis is a (for the moment) experimental change to the menu generation that should be discussed amongst experts and in a trigger core SW meeting.
Move the `AccumulatorCache` to the `getStep` method and remove it from the signature-specif...This is a (for the moment) experimental change to the menu generation that should be discussed amongst experts and in a trigger core SW meeting.
Move the `AccumulatorCache` to the `getStep` method and remove it from the signature-specific files. The actual change to review is in `ChainConfigurationBase.py` .
In addition, do not `deepcopy` the result of the sequence configuration (`ChainStep`) as it is not being re-used or modified afterwards. This was also the behavior of the original `RecoFragmentsPool` before it was migrated to `AccumulatorCache`. The deepcopy can be enabled again by setting `Trigger.fastMenuGeneration=False`.
**Reduces the menu generation time of Dev_pp_run3_v1 by a factor 2**. It does however introduce (harmless) changes in the order of some of the `HypoTools` and `InputMakerInputDecisions` properties. In case we decide to move forward with this we would definitely want to add an ART test that checks the configuration is equivalent with/without `fastMenuGeneration` (see this recent [confTool improvement](https://gitlab.cern.ch/atlas/athena/-/merge_requests/69329 "confTool: add ignoreOrder command line option")).
E.g. in the HI menu, the following properties change order (many more in the pp menu):
```plaintext
IM_EFMuMSReco_RoI.InputMakerInputDecisions
IM_L2MuCombReco.InputMakerInputDecisions
SPCountHypoAlg.HypoTools
TrigHIFwdGapHypoAlg.HypoTools
TrigL2MuCBHypoAlg.HypoTools
TrigL2MufastHypoAlg.HypoTools
TrigMuonEFCombinerHypoAlg.HypoTools
TrigMuonEFMSonlyHypo_RoI.HypoTools
```
cc @tbold @fpastore @tamartin
Relates to [ATR-26996](https://its.cern.ch/jira/browse/ATR-26996).https://gitlab.cern.ch/atlas/athena/-/merge_requests/69219Fix offline tau distributions in the Tau Trigger Monitoring2024-02-27T09:34:05+01:00Jean Yves Beaucampjean.yves.beaucamp@cern.chFix offline tau distributions in the Tau Trigger MonitoringFix for the offline taus pt threshold cut units in the `TrigTauMonitoring` package.Fix for the offline taus pt threshold cut units in the `TrigTauMonitoring` package.