athena merge requestshttps://gitlab.cern.ch/atlas/athena/-/merge_requests2024-01-08T15:56:19+01:00https://gitlab.cern.ch/atlas/athena/-/merge_requests/67628Make Input.RunNumber, Input.LumiBlockNumber and Input.TimeStamp in plural as ...2024-01-08T15:56:19+01:00Tadej Novaktadej.novak@cern.chMake Input.RunNumber, Input.LumiBlockNumber and Input.TimeStamp in plural as they are used as listMake `Input.RunNumber`, `Input.LumiBlockNumber` and `Input.TimeStamp` in plural as they are used as list.
The validation of the type will be implemented in a separate MR.
This also fixes run number argument parsing in reco and MC chann...Make `Input.RunNumber`, `Input.LumiBlockNumber` and `Input.TimeStamp` in plural as they are used as list.
The validation of the type will be implemented in a separate MR.
This also fixes run number argument parsing in reco and MC channel number handling in some derivation code as it was used incorrectly.
/cc @jchapman @nstyles @jcatmore @fwinklhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/66598GeneratorObjects: Avoid atomic operations on shared_ptr.2023-10-23T23:56:14+02:00Scott SnyderGeneratorObjects: Avoid atomic operations on shared_ptr.Atomic operations on shared_ptr turn out to be surprisingly expensive.
Rework HepMcParticleLink to use CachedValue rather than holding an atomic
shared_ptr. We can avoid having HepMcParticleLink increase in size by
declaring the CachedV...Atomic operations on shared_ptr turn out to be surprisingly expensive.
Rework HepMcParticleLink to use CachedValue rather than holding an atomic
shared_ptr. We can avoid having HepMcParticleLink increase in size by
declaring the CachedValue as no_unique_address. Then m_evtColl can occupy
the trailing padding of the CachedValue.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/62680Update to LCG_102b_ATLAS_19 to pick up HepMC3 3.2.6 (ATEAM-904)2023-04-28T21:42:06+02:00John Derek ChapmanUpdate to LCG_102b_ATLAS_19 to pick up HepMC3 3.2.6 (ATEAM-904)Update from LCG_102b_ATLAS_17 to LCG_102b_ATLAS_19 [SPI-2340](https://sft.its.cern.ch/jira/browse/SPI-2340)
to move from HepMC3 3.2.4 to HepMC3 3.2.6 (ATEAM-904). We expect this to be transparent (optimizations only),
but testing in ~ma...Update from LCG_102b_ATLAS_17 to LCG_102b_ATLAS_19 [SPI-2340](https://sft.its.cern.ch/jira/browse/SPI-2340)
to move from HepMC3 3.2.4 to HepMC3 3.2.6 (ATEAM-904). We expect this to be transparent (optimizations only),
but testing in ~master first before considering updating the HepMC3 version in ~"23.0".
The `ReadHepEvtFromAscii` algorithm does not compile with HepMC3 3.2.6 (@ewelina has confirmed that it is already broken anwayay). We aren't quite ready to drop it completely from the repo, so for now it is suppressed from HepMC3-based builds using preprocessor commands. NB The `HepMCReadFromFile` algorithm provides all the same functionality anyway.
Tagging @emoyse, @jcatmore, @nstyles, @ewelina, @averbyts, @tlari, @mbandierhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/62660[AGENE-2186] Parameter stage 21.62023-07-05T14:43:54+02:00Andrej Saibel[AGENE-2186] Parameter stage 21.6Dear all,
this MR adds a functionality to PowhegControl to change settings on the fly during the production in each of the parallelstages.
An example config is provided. The config changes fakevirt to 1 for parallelstage 1. Then the par...Dear all,
this MR adds a functionality to PowhegControl to change settings on the fly during the production in each of the parallelstages.
An example config is provided. The config changes fakevirt to 1 for parallelstage 1. Then the parameter is changed back to 0 for the following stages.
Kind regards,
Andrejhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/60530GenEvent: use references2023-02-09T21:43:34+01:00Tadej Novaktadej.novak@cern.chGenEvent: use referencesUse references in `GenEvent` for hotspot operations. We're still hit by slow `attributes` retrieval. Will open a ticket for that soon.
Note that I did that blindly (some may be redundant), but I already see 2x the speedup in HITS merge....Use references in `GenEvent` for hotspot operations. We're still hit by slow `attributes` retrieval. Will open a ticket for that soon.
Note that I did that blindly (some may be redundant), but I already see 2x the speedup in HITS merge. Relates to ATLASSIM-6384.
/cc @averbyts @jchapman @tlari @mbandier @ewelinahttps://gitlab.cern.ch/atlas/athena/-/merge_requests/59525Fix sorting of weight vector2023-01-03T09:42:08+01:00Matthew GignacFix sorting of weight vectorHepMCWeightSvc was sorting the weight name map incorrectly. Since HepMCWeightSvc is used to load the weight map when reading GenEvent from the McEventCollection in EVNT files, the weight map that propagated to GenEvent was incorrect.
AG...HepMCWeightSvc was sorting the weight name map incorrectly. Since HepMCWeightSvc is used to load the weight map when reading GenEvent from the McEventCollection in EVNT files, the weight map that propagated to GenEvent was incorrect.
AGENE-2169
Tagging @cgutscho, @dhirschhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/42398Remove printout of PACKAGE_VERSION2021-04-10T03:04:51+02:00Frank WinklmeierRemove printout of PACKAGE_VERSIONThe `PACKAGE_VERSION` macro is irrelevant in git-based releases (it defaults to `PackageName-00-00-00`). Remove this printout in various packages.The `PACKAGE_VERSION` macro is irrelevant in git-based releases (it defaults to `PackageName-00-00-00`). Remove this printout in various packages.https://gitlab.cern.ch/atlas/athena/-/merge_requests/41707adding xAOD truth to HepMC GenEvent conversion2021-05-06T03:06:05+02:00Aidan Sean Kellyadding xAOD truth to HepMC GenEvent conversionThe purpose of this change set is to pull some logic (e.g. the `TruthConverter`) from 21.2 and use (+ extend) it in `Rivet_i` to allow AODs and TRUTH1 DAOD to be read in and their xAOD::Truth format to be converted back to HepMC::GenEven...The purpose of this change set is to pull some logic (e.g. the `TruthConverter`) from 21.2 and use (+ extend) it in `Rivet_i` to allow AODs and TRUTH1 DAOD to be read in and their xAOD::Truth format to be converted back to HepMC::GenEvent, so that it can be passed on to Rivet.https://gitlab.cern.ch/atlas/athena/-/merge_requests/31619Switch to HepMcParticleLink_p3-based persistency2020-04-02T19:05:15+02:00John Derek ChapmanSwitch to HepMcParticleLink_p3-based persistency`HepMcParticleLink_p3` uses `unsigned int` rather than `unsigned short` to hold the eventIndex. This is a step towards preventing the aliasing of higher event numbers seen with `HepMcParticleLink_p2`. This merge request does not change t...`HepMcParticleLink_p3` uses `unsigned int` rather than `unsigned short` to hold the eventIndex. This is a step towards preventing the aliasing of higher event numbers seen with `HepMcParticleLink_p2`. This merge request does not change the transient `HepMcParticleLink` class, so it won't fix the problem on its own. The downside is that it will increase the size of events on disk. The size of this effect will need to be determined before the change is merged.
NB This will (temporarily) break the ability to read files produced in ~"21.9" with other branches.https://gitlab.cern.ch/atlas/athena/-/merge_requests/27166Fix OpenLoop Path for Powheg-Box-Res processes ttbb and bblvlv2019-10-21T14:57:37+02:00Timothee Theveneaux-PelzerFix OpenLoop Path for Powheg-Box-Res processes ttbb and bblvlvThe changes in PowhegControl update the hack for OpenLoops path problem for the ttbb Powheg-Box-Res process - in order to not completely hardcode the path - and implements the same for bblvlv, as discussed in AGENE-1638. The same can be ...The changes in PowhegControl update the hack for OpenLoops path problem for the ttbb Powheg-Box-Res process - in order to not completely hardcode the path - and implements the same for bblvlv, as discussed in AGENE-1638. The same can be used for other Powheg-Box-Res processes if need be.https://gitlab.cern.ch/atlas/athena/-/merge_requests/69998Reduce the usage of #ifdef HEPMC32024-03-21T11:53:38+01:00Andrii VerbytskyiReduce the usage of #ifdef HEPMC3Reduce the usage of #ifdef HEPMC3
@pclark @jchapmanReduce the usage of #ifdef HEPMC3
@pclark @jchapmanhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69721Update to LCG_104d_ATLAS_9, main branch (2024.03.11.)2024-03-18T11:47:30+01:00Attila KrasznahorkayUpdate to LCG_104d_ATLAS_9, main branch (2024.03.11.)This is a slightly bigger update, switching the ~main branch to using [LCG_104d_ATLAS_9](https://lcginfo.cern.ch/release/104d_ATLAS_9/), as discussed in ATLINFR-5281.
The new LCG layer comes with the following updates: https://lcginfo.c...This is a slightly bigger update, switching the ~main branch to using [LCG_104d_ATLAS_9](https://lcginfo.cern.ch/release/104d_ATLAS_9/), as discussed in ATLINFR-5281.
The new LCG layer comes with the following updates: https://lcginfo.cern.ch/compare_releases/None/104d_ATLAS_9/104d_ATLAS_7, as discussed in SPI-2517. The (from a technical perspective) important updates being:
- Rivet was updated from version `3.1.10` to `4.0.0`. But only in [LCG_104d_ATLAS_9](https://lcginfo.cern.ch/release/104d_ATLAS_9/). [LCG_104d_ATLAS_10](https://lcginfo.cern.ch/release/104d_ATLAS_10/) remained on version `3.1.10`, as the new version is not compatible with HepMC2 anymore.
* This required adding some pre-processor choices in [Rivet_i](Generators/Rivet_i) and [TruthRivetTools](Generators/TruthRivetTools) to allow both the HepMC3 and HepMC2 based nightlies to continue functioning. :thinking:
- Re-introduced CUDA into the ATLAS layer with CUDA 12.4, which finally supports GCC 13.
- Also re-introduced cuDNN, with version 8.9.7.
To account for the Rivet and CUDA changes, had to update the externals to [atlasexternals-2.1.12](https://gitlab.cern.ch/atlas/atlasexternals/-/tags/2.1.12). Which comes with the following updates (https://gitlab.cern.ch/atlas/atlasexternals/-/compare/2.1.10...2.1.12):
- Introduced `FindHighFive.cmake` for the correspondingly named external;
* This is a header-only package that Rivet 4.0.0 depends on. And I see just now that [LCG_104d_ATLAS_10](https://lcginfo.cern.ch/release/104d_ATLAS_10/) misses HighFive as well. :thinking: So I may need to tweak the CMake configuration of the two affected packages a bit more, to not break the HepMC2 nightlies right away...
- Changed [External/onnxruntime](https://gitlab.cern.ch/atlas/atlasexternals/-/tree/main/External/onnxruntime?ref_type=heads) to download a pre-built binary of ONNXRuntime instead of building it itself;
* Updated `Findonnxruntime.cmake` to handle the different header layout coming with the pre-built binaries.
The ONNXRuntime change was made to avoid spending a loooong time with figuring out how to make ONNXRuntime build successfully with CUDA 12.4, cuDNN 8 and GCC 13. (It didn't do so out of the box. :frowning:) But this required the include statements for all ONNXRuntime headers to be updated. Since as it turns out, our custom build was not installing the ONNX headers quite correctly so far. :thinking:https://gitlab.cern.ch/atlas/athena/-/merge_requests/69581Andrej Saibel corrections to SFGen Athena interface2024-03-13T15:26:16+01:00Lorenzo Primomo164021@spes.uniud.itAndrej Saibel corrections to SFGen Athena interfaceThis is the merge request for the SFGen interface with some small correction suggested by @asaibel. Tagging @gpanizzo and @ewelina .
FIX AGENE-2074This is the merge request for the SFGen interface with some small correction suggested by @asaibel. Tagging @gpanizzo and @ewelina .
FIX AGENE-2074https://gitlab.cern.ch/atlas/athena/-/merge_requests/69387GeneratorFilters: fix logic of the (xAOD)XtoVVDecayFilterExtended.cxx2024-03-01T20:15:16+01:00Ewelina Maria LobodzinskaGeneratorFilters: fix logic of the (xAOD)XtoVVDecayFilterExtended.cxxfix logic of the (xAOD)XtoVVDecayFilterExtended.cxx
to be consistent with what is done for HepMC2 version of the filter,
in the current HepMC3 approach one generation of the ancestors was skipped
For info @qidongfix logic of the (xAOD)XtoVVDecayFilterExtended.cxx
to be consistent with what is done for HepMC2 version of the filter,
in the current HepMC3 approach one generation of the ancestors was skipped
For info @qidonghttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69109EvgenJobTransform: add printout if HepMC version to the log2024-02-22T17:05:11+01:00Ewelina Maria LobodzinskaEvgenJobTransform: add printout if HepMC version to the logEvgenJobTransform: add printout if HepMC version to the log, as requested by @sargyropEvgenJobTransform: add printout if HepMC version to the log, as requested by @sargyrophttps://gitlab.cern.ch/atlas/athena/-/merge_requests/69097update to LCG_104d_ATLAS_52024-03-06T13:06:10+01:00Ewelina Maria Lobodzinskaupdate to LCG_104d_ATLAS_5update to LCG_104d_ATLAS_5
The only changes are generator versions:
Pythia8.308
EvtGen2.1.1
MG 3.5.1.atlas3
Herwig7.2.3p2update to LCG_104d_ATLAS_5
The only changes are generator versions:
Pythia8.308
EvtGen2.1.1
MG 3.5.1.atlas3
Herwig7.2.3p2https://gitlab.cern.ch/atlas/athena/-/merge_requests/69055HepMcParticleLink Drop support for separate McEventCollections for pile-up truth2024-02-26T10:36:09+01:00John Derek ChapmanHepMcParticleLink Drop support for separate McEventCollections for pile-up truthThe idea of having separate McEventCollection instances for each type of pile-up used was never used in production and with the ability to decorate GenEvents directly with this information using Attributes is now completely redundant.
R...The idea of having separate McEventCollection instances for each type of pile-up used was never used in production and with the ability to decorate GenEvents directly with this information using Attributes is now completely redundant.
Removing this will simplify the HepMcParticleLink EDM. Unfortunately due to the large number of client classes then this merge request is quite large. Here is a breakdown to ease the review process:
1. The main changes are in the `Generators/GeneratorObjects` package. Removing the obsolete code and in particular revising the `ExtendedBarCode` and `HepMcParticleLink` constructor syntax.
1. The next set of changes are in `MuonSpectrometer/MuonPhaseII/Event/xAOD/xAODMuonSimHit/Root/xAODMuonSimHit_V1.cxx` and `InnerDetector/InDetEventCnv/InDetSimEventTPCnv/src/InDetHits/*.cxx` hard-coding variables in some persistent class objects to the only value ever used in production. (Future versions of these persistent classes will drop this variable, but that will be a separate merge request.)
1. The next set of changes are in the various TP converter test classes - avoiding checks on the variable(s) now removed from the transient HepMcParticlelink class.
1. The rest of the changes are dropping the obsolete arguments from HepMcParticleLink constructor calls.
Tagging @ewelina, @averbyts, @pclarkhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/68585Add Generator config flags to prepare move to CA configuration. See !672332024-02-05T16:29:47+01:00Spyros ArgyropoulosAdd Generator config flags to prepare move to CA configuration. See !67233- Introduce `GeneratorConfigFlags` in `GeneratorConfig` package to prepare the move to CA configuration (splitting from !67233)
- Add function to call `createGeneratorConfigFlags()` in `AllConfigFlags`
cc @ewelina @tadej- Introduce `GeneratorConfigFlags` in `GeneratorConfig` package to prepare the move to CA configuration (splitting from !67233)
- Add function to call `createGeneratorConfigFlags()` in `AllConfigFlags`
cc @ewelina @tadejhttps://gitlab.cern.ch/atlas/athena/-/merge_requests/67541Adding keywords to evgen metadata2023-12-02T05:41:50+01:00Zach MarshallAdding keywords to evgen metadataKeywords in event generation specify various things about the process
being generated - what physics it might represent, what particles are
being generated, and so on.
These keywords are extremely handy downstream for auto configuration...Keywords in event generation specify various things about the process
being generated - what physics it might represent, what particles are
being generated, and so on.
These keywords are extremely handy downstream for auto configuration.
See for example the discussion in !67455. Similarly, one can configure
SUSY helpers for all SUSY samples based on keyword, or Higgs helpers for
all Higgs samples, and so on.
This adds the keywords to the EVNT metadata, so that they can be
transferred along and accessed downstream. It'll be a long time before
all our evgen have these keywords, but better to start the process now.