athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2024-03-25T11:04:21+01:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/69896JpsiUpsilonTools: Fix to skip GSF J/psi tracks (originally worked only for ID...2024-03-25T11:04:21+01:00Tomas JakoubekJpsiUpsilonTools: Fix to skip GSF J/psi tracks (originally worked only for ID tracks).In the BLS package JpsiUpsilonTools, there are two places where we want to skips ID TrackParticles if these are used to build a J/psi candidate. However, we use GSF TrackParticles for electrons and the "simple" (original) comparison didn...In the BLS package JpsiUpsilonTools, there are two places where we want to skips ID TrackParticles if these are used to build a J/psi candidate. However, we use GSF TrackParticles for electrons and the "simple" (original) comparison didn't work for them, leading to e.g. Bd-meson candidate (should be 4 different TracksParticles) built from 2 GSF TrackParticles + their 2 original ID TrackParticles.
The fix uses already defined property UseGSFTrackIndices, thus no change in a setup is needed.
This fix is crucial for BPHY18 (R(K*) analaysis), where it removes these spoiled Bd/BdBar candidates (which makes the DAOD smaller). It does NOT affect any other derivation/analysis or any default behaviour.Tomas JakoubekTomas Jakoubekhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69766Update BPHY252024-03-14T16:15:10+01:00Xin ChenUpdate BPHY25Updated BPHY25 in release 21.2 with two major things:
1) Adding V0 daughters' momenta without mass constraint to the V0 vertex (before mass-constrained refit) as decorations.
2) Removing Jpsi subvertex in the cascade tree since Jpsi is n...Updated BPHY25 in release 21.2 with two major things:
1) Adding V0 daughters' momenta without mass constraint to the V0 vertex (before mass-constrained refit) as decorations.
2) Removing Jpsi subvertex in the cascade tree since Jpsi is not long-lived, although it is not technically wrong (but should better make it correct physics-wise according to Vadim).
And some other code tidy-up.Xin ChenXin Chenhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69212SUSYTool - Change default systematic strategy for flavor tagging2024-02-28T19:36:33+01:00Michael HolzbockSUSYTool - Change default systematic strategy for flavor taggingPropagate the adjustment which is done for main in !69079 also to 21.2
For reference: a first attempt of this was done in !69078 but aborted as the CI tests failed due to outdated reference files. These have been already updated so the...Propagate the adjustment which is done for main in !69079 also to 21.2
For reference: a first attempt of this was done in !69078 but aborted as the CI tests failed due to outdated reference files. These have been already updated so the CI should work now.
Tagging @mhank .https://gitlab.cern.ch/atlas/athena/-/merge_requests/68570BPHY13, 23 and 25 update2024-02-28T15:03:14+01:00Xin ChenBPHY13, 23 and 25 updateUpdated BPHY13, BPHY23 and BPHY25. For BPHY13, made 4-muon single-vertex fit with charmonium mass constraints (instead of replying on charmonium revertex). For BPHY23, added the multi-track single-vertex fitter and corresponding changes ...Updated BPHY13, BPHY23 and BPHY25. For BPHY13, made 4-muon single-vertex fit with charmonium mass constraints (instead of replying on charmonium revertex). For BPHY23, added the multi-track single-vertex fitter and corresponding changes in python. For BPHY25, removed Ks and added 3-body decays like B- -> J/psi Lambda pbar, and corresponding changes in python.
Development of BPHY13, BPHY23 and BPHY25 can be found in the following JIRAs:
https://its.cern.ch/jira/browse/ATLBPHYS-34
https://its.cern.ch/jira/browse/ATLBPHYS-219
https://its.cern.ch/jira/browse/ATLBPHYS-298Xin ChenXin Chenhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/68331Fix bugs in the random seeding of the JER uncertainty2024-02-21T12:05:54+01:00Christopher YoungFix bugs in the random seeding of the JER uncertainty@markowen found that the JER was using the same seed for smearing jets as is done in JetCalibTools. This results in a correlated smearing and a large over-estimation of the uncertainty. Additionally, as most people use MC as pseudo-data ...@markowen found that the JER was using the same seed for smearing jets as is done in JetCalibTools. This results in a correlated smearing and a large over-estimation of the uncertainty. Additionally, as most people use MC as pseudo-data it is more correct to use the max(MC,data) resolution. This was not anticipated when the tool was originally written but results in very small changes. Finally advanced users can set the seed themselves, but this currently set the seed the same for all jets which is not a usual use-case so this has also been modified.https://gitlab.cern.ch/atlas/athena/-/merge_requests/63605AnalysisTop: fix loose electron reco SFs and experimental settings2024-02-21T08:32:53+01:00Baptiste Ravinabaptiste.ravina@cern.chAnalysisTop: fix loose electron reco SFs and experimental settingsAs reported by @cnass, we attempt to retrieve a "loose electron reco SF" that doesn't exist. Furthermore, the experimental setting forcing a different electron isolation SF was looking for the wrong decoration (the equivalent code for mu...As reported by @cnass, we attempt to retrieve a "loose electron reco SF" that doesn't exist. Furthermore, the experimental setting forcing a different electron isolation SF was looking for the wrong decoration (the equivalent code for muons is correct).https://gitlab.cern.ch/atlas/athena/-/merge_requests/68718Nightly Trigger Update, 21.2 branch (2024.02.08.)2024-02-08T21:52:52+01:00Attila KrasznahorkayNightly Trigger Update, 21.2 branch (2024.02.08.)Synchronized `Athena/version.txt` with `AnalysisBase/version.txt`. Purely to trigger a new nightly build for @robouque for Friday, as discussed on ATLINFR-5242. :wink:
@aundrus, I only saw your message on JIRA now. :frowning: I'll just ...Synchronized `Athena/version.txt` with `AnalysisBase/version.txt`. Purely to trigger a new nightly build for @robouque for Friday, as discussed on ATLINFR-5242. :wink:
@aundrus, I only saw your message on JIRA now. :frowning: I'll just merge this in quickly, now that I already set everything up...https://gitlab.cern.ch/atlas/athena/-/merge_requests/68392New derivation format: BPHY262024-01-31T15:26:16+01:00Yue XuNew derivation format: BPHY26We would like to request for a new derivation format -- BPHY26. The ART tests for BPHY26 are also created.We would like to request for a new derivation format -- BPHY26. The ART tests for BPHY26 are also created.https://gitlab.cern.ch/atlas/athena/-/merge_requests/68306PhysicsAnalysis/DerivationFramework/DerivationFrameworkSUSY/share/SUSY6.py: A...2024-01-24T12:04:01+01:00Nathan Dale YoungPhysicsAnalysis/DerivationFramework/DerivationFrameworkSUSY/share/SUSY6.py: Adding r-tag into list of SUSY6 for newly available samplesThis MR adds the r-tags of new signal samples into the list of DAOD_RPVLL samples which toggles filtering to keep the derivation sizes smaller. These samples are for the SUSY disappearing track group which relies on special reconstructio...This MR adds the r-tags of new signal samples into the list of DAOD_RPVLL samples which toggles filtering to keep the derivation sizes smaller. These samples are for the SUSY disappearing track group which relies on special reconstruction techniques.
The added r-tags are based on samples produced here: [https://its.cern.ch/jira/browse/ATLMCPROD-10493](https://its.cern.ch/jira/browse/ATLMCPROD-10493)
and here: [https://its.cern.ch/jira/browse/ATLMCPROD-10713](https://its.cern.ch/jira/browse/ATLMCPROD-10713)https://gitlab.cern.ch/atlas/athena/-/merge_requests/68166Fix missing mcChannelNumber and add BTagging to EXOT152024-01-17T10:37:01+01:00Alexander BasanFix missing mcChannelNumber and add BTagging to EXOT15Application of GRL to data events caused mcChannelNumber to disappear. Fix this by checking the SkipTriggerRequirement as for the EXOT15MCThinningTool. Add AntiKt4EMTopoJets_BTagging201810 and BTagging_AntiKt4EMTopo_201810 containers to ...Application of GRL to data events caused mcChannelNumber to disappear. Fix this by checking the SkipTriggerRequirement as for the EXOT15MCThinningTool. Add AntiKt4EMTopoJets_BTagging201810 and BTagging_AntiKt4EMTopo_201810 containers to enable BTagging.
This is for a study to extend the CalRatio analysis to include tops in the final state. Currently being done in R21. Currently there’s no b-tagging information in EXOT15, and when adding it, we found a bug affecting mcChannel, introduced some releases ago.https://gitlab.cern.ch/atlas/athena/-/merge_requests/67985Set correct values for large-R truth label2024-01-09T16:57:30+01:00Chris Malena DelitzschSet correct values for large-R truth labelA bug was discovered for the large-R truth labels `R10TruthLabel_R21Precision` and `R10TruthLabel_R21Precision_2022v1` (not present in main). For these labels, the tool always defaulted back to the trimmed truth jets rather than the ungr...A bug was discovered for the large-R truth labels `R10TruthLabel_R21Precision` and `R10TruthLabel_R21Precision_2022v1` (not present in main). For these labels, the tool always defaulted back to the trimmed truth jets rather than the ungroomed truth jets `AntiKt10TruthJets` because the values were not set in the initialize function but earlier when setting up the tool which does not work. To be able to run the correct truth labelling, the splitting scale variables `Split12` and `Split23` have to be reconstructed for the `AntiKt10TruthJets` which is handled by the changes to JetCommon.
Happy holidays!
Tagging @fballi @camacho @dcamarer @mdiamant @jzahredd @rleshttps://gitlab.cern.ch/atlas/athena/-/merge_requests/67844BPHY22: adding container to the output2023-12-18T14:51:37+01:00Laily SultanaliyevaBPHY22: adding container to the outputWith new update the container with two track candidate (BPHY22DiTrkCandidates) will be stored in the output files.With new update the container with two track candidate (BPHY22DiTrkCandidates) will be stored in the output files.https://gitlab.cern.ch/atlas/athena/-/merge_requests/66591Sweeping !66528 from main to 21.2.
correctly pass x509userproxy to condorClos...2023-12-11T16:36:23+01:00Atlas NightlybuildSweeping !66528 from main to 21.2.
correctly pass x509userproxy to condorCloses ATLASG-2561correctly pass x509userproxy to condor
Closes ATLASG-2561
See merge request atlas/athena!66528correctly pass x509userproxy to condor
Closes ATLASG-2561
See merge request atlas/athena!66528https://gitlab.cern.ch/atlas/athena/-/merge_requests/29260Adding fix for logic bug with JetCaloClusterThinning and JetPFlowThinning2023-12-07T22:38:08+01:00Jennifer RoloffAdding fix for logic bug with JetCaloClusterThinning and JetPFlowThinningThis MR is addressing the logic bug noted in ATLASG-1520 for JetCaloClusterThinning and JetPFlowThinning. It ensures that the thinning is applied regardless of whether there are any jets in the event.
I have tested that the output looks...This MR is addressing the logic bug noted in ATLASG-1520 for JetCaloClusterThinning and JetPFlowThinning. It ensures that the thinning is applied regardless of whether there are any jets in the event.
I have tested that the output looks reasonable, and I am happy to do any other checks that would be helpful.https://gitlab.cern.ch/atlas/athena/-/merge_requests/67495DerivationFrameworkMCTruth: adding yet another DSIDs to the list for heavy fl...2023-12-05T10:58:42+01:00Roman LysakDerivationFrameworkMCTruth: adding yet another DSIDs to the list for heavy flavour origin classifiersimilarly as in MR67401, this MR adds 2 ttbar FSR samples to the HF list
tagging: @boeriusimilarly as in MR67401, this MR adds 2 ttbar FSR samples to the HF list
tagging: @boeriuhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/65314Saving Truth information on extra partons in ttbar events2023-12-04T09:34:54+01:00Mohamed AlySaving Truth information on extra partons in ttbar eventsThere currently exists an algorithm to save the truth-level partons in a ttbar production. However, that algorithm does not save any information on extra partons in the event that are not related to the ttbar system. This MR introduces a...There currently exists an algorithm to save the truth-level partons in a ttbar production. However, that algorithm does not save any information on extra partons in the event that are not related to the ttbar system. This MR introduces a new module with an implementation of an algorithm to get the interesting extra partons in an event, that could then lead to extra jets at reco-level.
In particular, the algorithm concerns itself with extra partons emerging from 2 sourceS:
- The hard proces, that could be (gq->ttq) or (gg->ttqq)
- ISR/FSR (and MPIs that follows them)
The code intentionally does not try to find partons from back-evolution, proton-remenants or hadronisation.
The algorithm is only usable with `Pythia8` since it relies on the use of status codes that are currently only well defined in `Pythia8`. The status codes are critical in this case to be able to disentangle the various sources of quarks, and simplify the scan over the entire record of quarks in the event (and all versions of each quark).
The algorithm implemented tries to follow gluon lines all the way to a parton, either by following a gluon splitting then following each of the children to their post-FSR versions, or by following the outgoing partons of a 2->2 secondary (sub)process (gq->gq or qq->qq) and again following them to their post-FSR versions. A pseudo-code description is attached in some slides to this MR.
This implementation is motivated by some truth-level checks we wanted to do, to understand the structure of the diagrams entering our analysis phase-space. I do recognise that these partons should not be used to make any "preicise" or "exact" conclusions, but we would like to use them to be able to understand the broad underlying structure of the tt+jets events we have. This is in-light of trying to compare the physics of the tt+>1b diagrams in 5FS ttbar-inclusive simulation and ttbb diagrams in 4FS simulation and understand the difference between the two MCs.
When a parton is found, the parent of the parton is saved, and the post-FSR version of that parton is also saved. The information kept on the parton are: `pT`, `eta`, `phi`, `m`, `pdgId` and `status`. The same information is kept for the parent, as well as the parent's `barcode`. With these branches saved, one can idenitify the origin of quarks via their parents, find those coming from the same parent (e.g. gluon splitting) and then do simple studies on the kinematics of the partons right before they enter hadronisation. Following this method, partons saved are expected to be ready to undergo hadronisation. The partons are saved after ordering them in pT and choosing first 12 partons.
There is a fraction of the partons saved whose status codes are not directly hinting that the parton is going to undergo hadronisation (not status >70). They are often split into 2 types:
1) The parton has no children at all
2) The parton has > 2 children, most of which are mesons with status 1 or 2
In the first case, I have no idea what's happening.
In the second case I would naively think that some copies (e.g. with status 71) of the parton that are used to start hadronisation get dropped from the record and the results of first round of hadronisation is attached directly to the parton coming from some radiation in the event. I suppose this is possible if the virtuality of the 71 parton is really large, which is a metric used by some generators to clean the record and can result in missing intermediate partons.
I am not sure what validaiton tests would be appropriate/conclusive for such implementation. I have done simple checks to make sure that all partons being accounted for did indeed start from hard process or MPI or ISR/FSR. I also compared the number of hard process extra jets in 5FS ttbar sample vs 4FS ttbb sample, finding that the 4FS sample does indeed result in 2 extra b-partons being saved every time, and they are always the hardest extra partons in the event.
[250823_MoAly_SummaryOfExtraQuarksTruthImplementation.key](/uploads/e2c4ff552438ca47dc0b734b44bda930/250823_MoAly_SummaryOfExtraQuarksTruthImplementation.key)
Tagging contacts and experts: @vvecchio @cescobar @nbruscinhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/67454Update version.txt2023-11-29T11:48:03+01:00Emma Torro PastorUpdate version.txtUpdating R21 derivation cacheUpdating R21 derivation cachehttps://gitlab.cern.ch/atlas/athena/-/merge_requests/67386Add pileup truth info for MC derivations to JETM7 scheme2023-11-28T18:33:09+01:00Carlos Moreno MartinezAdd pileup truth info for MC derivations to JETM7 schemeAdding a few missing containers needed for MC studies with this derivation scheme.Adding a few missing containers needed for MC studies with this derivation scheme.https://gitlab.cern.ch/atlas/athena/-/merge_requests/67394DerivationFrameworkHiggs: Add new HWW ggH samples to HiggsMCSamples config2023-11-28T18:29:23+01:00Robin HayesDerivationFrameworkHiggs: Add new HWW ggH samples to HiggsMCSamples configAdds the DSID of two new alternate ggH FxFx samples used by HWW analyses to the HiggsMCSamples config, since STXS labels are required for these.Adds the DSID of two new alternate ggH FxFx samples used by HWW analyses to the HiggsMCSamples config, since STXS labels are required for these.https://gitlab.cern.ch/atlas/athena/-/merge_requests/67401DerivationFrameworkMCTruth: adding DSIDs to the list for heavy flavour origin...2023-11-28T17:43:43+01:00Roman LysakDerivationFrameworkMCTruth: adding DSIDs to the list for heavy flavour origin classifierThe ttH(bb) legacy analysis would like to try out some dedicated ttbar FSR variation samples to remedy pulls.
The four DSIDs need to be added to the heavy flavour classification tool in the R21.
For more details, see https://its.cern.c...The ttH(bb) legacy analysis would like to try out some dedicated ttbar FSR variation samples to remedy pulls.
The four DSIDs need to be added to the heavy flavour classification tool in the R21.
For more details, see https://its.cern.ch/jira/browse/ANALYSISTO-1365
This MR adds these 4 DSIDs.
tagging: @boeriu