ALICE 3: proc_id is actually a long

[ddobrigk]

...does not yet guarantee PYTHIA will accept it!

[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-apass3
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0

[ddobrigk]

@benedikt-voelkel @sawenzel, @jesgum just checked that this PR is definitely necessary (but not necessarily sufficient) for the seed usage in PYTHIA for MCGEN trains. Can you please merge?

The other issue is that PYTHIA seeds are max-limited to 900M, and job IDs can exceed that. Maybe this was dealt with already in the main simulation framework? If so, how?... Thanks!!!

[ddobrigk]

Hi again, sorry for the spam - maybe the vars set in setVarsFromALIEN_PROC_ID.sh are the better ones for the seed set? Perhaps the int16 version, for instance, of the ALIEN_PROC_ID? ...

[ddobrigk]

@jesgum I changed such that we only use bits 0-28 from the proc id. Can you please give this a try with your local setup? Many thanks! I'm reverting to draft until checked.

[ddobrigk]

@jesgum has tested this, and everything works flawlessly - and we should have perfect handling of seeds, as we'll be giving seeds to PYTHIA that go from 0 to 536870911 (which is allowed by PYTHIA). @sawenzel @benedikt-voelkel can we please merge if that's alright with you? Thank you very much!