Add Angantyr O-O cfg

[ddobrigk]

No description provided.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[jackal1-66]

Ciao @ddobrigk, an example of OO configuration has been merged already in AliceO2 via this PR: AliceO2Group/AliceO2#14190 . It's the most basic configuration one could think of at 10.72 TeV. I'm not against your configuration as well, considering it contains also additional parameters and an eCM of 6.8 TeV, but wanted to understand if it has a specific purpose.

[ddobrigk]

Hi @jackal1-66 , thanks for having a look! Just to clarify here, the point is to have an O-O (and possibly then also a p-O) configuration to be able to run simulations with it, and I suppose O2DPG is where these simulations are defined. @sawenzel, of course, please don't hesitate to jump up in case of a misunderstanding!

I think it would be then best to include also the p-O together in this PR and adjust the energy, since it seems O-O will be at 5.36 TeV to match the per-nucleon energy of Pb-Pb and I had missed that. Will adjust accordingly

[jackal1-66]

In the meantime I opened a PR to fix the default values provided in the .cfg files in AliceO2: AliceO2Group/AliceO2#14213. @ddobrigk thank you for raising the issue

[sawenzel]

@ddobrigk : Thanks for your initiative. We also started to prepare these scenarios alongside JIRA ticket https://its.cern.ch/jira/browse/O2-5914. @jackal1-66 made some configs available directly in O2, so that they can also be used in full-system testing on the EPN. Ideally we should avoid duplication.

For what concerns O2DPG MC (not hyperloop, not O2), the config can actually be generated using the tool mkpy8cfg.py based on input to the workflow generator and as a function of energy etc.

[ddobrigk]

Hi @sawenzel , of course, I agree we should not duplicate, but I have to admit I was somewhat confused that generator configs are now first in O2 and not in O2DPG, where - at least to my knowledge - this was standard. Am I to understand that the O2 version is the 'master' one and the rest is to be generated with the python script you point out and then put (with a manual PR) into O2DPG?

As for the duplication: I will close this soon then if the reply to the question above is yes :-)

Note, though, that the p-O is likely still not correct in @jackal1-66 's initialization, but I can comment this directly to the JIRA ticket then.

[sawenzel]

@ddobrigk : Yes your understanding is correct. In principle generator configurations for official MC productions should reside here.

There is a slight "but" for the fundamental Pythia8 configs:
(a) here we already offered some generic configs even in O2. For instance pythia8_hi.cfg, pythia8_pp.cfg. This is mainly to have some configs that can be used with o2-sim standalone. EPN data-flow testing also needs something with O-O etc. This is why we have put more files in O2.

(b) In O2DPG, the fundamental Pythia8 config is usually generated via mkpy8cfg.py. My hope is that we could cover the O-O cases also with this tool.

(c) Notwithstanding, we can have actual Pythia8 config files also in the actual O2DPG repo. You have already used this for ALICE3 studies a lot.

We can add your files also here, should it be convenient ... but for Run3 productions I would probably favour the standard route of using mkpy8cfg.py if this is possible.

[ddobrigk]

Hi @sawenzel - alright, thanks a lot! Then maybe, provided we can cover the O-O cases right away with the tool you propose, I will close this PR :-)

Just one very minor comment - for O-O in ALICE 3, we used the nominal-top energy (rigidity equivalent to pp 14TeV, which is then 7 TeV for O-O since mass number and atomic number are 2:1... and for 2025 O-O this won't be the right energy, so better have a separate cfg file.