PWGUD Starlight interface

[mbroz84]

Interface to STARlight generator that is used by UPC PAG. Some processes are eventually decayed by EvtGen that is interfaced in DQ, we use our own decay tables to avoid any conflict. Configuration .ini file is created by python script.
There are two issues that needs to be fixed before merging this PR:

1. STARlight 'as is' create only static library. I didn't manage to make it work that way so I changed the Cmake to make shared one in order to develop this. Is there any trick how to use static library (.a) in O2DPG?
2. STARlight uses #define printInfo .... that is in conflict with member methods with the same name in Pythia etc. Locally I changed the name of the preprocessor macro to avoid this. Is there any other trick to do this?

Then in the alidist we would need to define $STARLIGHT_ROOT variable and add it to PATH and LD_LIBRARY_PATH.

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

[sawenzel]

@mbroz84 : Interesting development. So you intend to use Starlight as a library and not in HepMC mode?

We need to do the changes in alidist and to Starlight that you have already laied out. No way to use a static lib. I can take care of changes to Starlight + alidist but I would need a testing shell script on your side (an invocation of the generator using an actual ini file). This is anyways required to test your generator setup in the CI (@benedikt-voelkel can give more details).

[mbroz84]

Hi, yes we want to STARlight as a library, its more practical and allow simple connection with EvtGen that we used also before in AliRoot. Concerning the script: you mean something like MC/run/PWG... ?

[sawenzel]

Hi, yes we want to STARlight as a library, its more practical and allow simple connection with EvtGen that we used also before in AliRoot. Concerning the script: you mean something like MC/run/PWG... ?

Yes, something of the sort (before comitting, you could send me an example so that I have something to test)

[mbroz84]

Hi, yes we want to STARlight as a library, its more practical and allow simple connection with EvtGen that we used also before in AliRoot. Concerning the script: you mean something like MC/run/PWG... ?

Yes, something of the sort (before comitting, you could send me an example so that I have something to test)

Attached is a script that creates the config and runs generator via o2-sim

runGenStarlight.txt

[sawenzel]

In principle everything is prepared. I asked for PRs to STARlight + alidist as described in the ticket https://its.cern.ch/jira/browse/O2-5076. Let's hope the STARlight team reacts quickly.

[benedikt-voelkel]

Approve to run CI

[benedikt-voelkel]

Hello @mbroz84
the basic CI goes through already.
Now, could I ask you to write an ini file (like e.g. LF has done here https://github.com/AliceO2Group/O2DPG/tree/master/MC/config/PWGLF/ini) and also put the corresponding test of that ini file like done https://github.com/AliceO2Group/O2DPG/tree/master/MC/config/PWGLF/ini/tests ?

In that way, the ini will be picked up for testing.
It's about very basic tests so that in a test script you can check if your generator does in principle what you expect it to do.

Let me know if you have further questions in that direction.

Some documentation is here: https://aliceo2group.github.io/simulation/docs/generators/generatorconfig.html#generator-tests

[mbroz84]

Hello @benedikt-voelkel I added two tests, one for STARlight alone and one for STARlight -> EvtGen

[mbroz84]

I don't get it... How I'm supposed to load the STARlight library? Apparently none of the two
R__LOAD_LIBRARY(libStarlib)
R__LOAD_LIBRARY($STARlight_ROOT/lib64/libStarlib.so)
works in CI tests even when the second works for me locally (with up-to-date alidist).

[sawenzel]

I don't get it... How I'm supposed to load the STARlight library? Apparently none of the two R__LOAD_LIBRARY(libStarlib) R__LOAD_LIBRARY($STARlight_ROOT/lib64/libStarlib.so) works in CI tests even when the second works for me locally (with up-to-date alidist).

We'll look into it.

[benedikt-voelkel]

I tested locally and both with O2sim and O2PDPSuite environment and I can confirm @mbroz84 observation that both cases pass.
From my point of view, we can merge this PR now. @sawenzel what do you think?

In the CI, the O2sim env should be loaded, so at this point, maybe there is some older cached version loaded for the CI test. Need to check.

[sawenzel]

Works for me in the combination

R__LOAD_LIBRARY(libStarlib.so)
R__ADD_INCLUDE_PATH($STARlight_ROOT/include)

[mbroz84]

For me locally (o2-sim environment) works only the second option (with full path) because in the LD_LIBRARY_PATH I see /home/brozmic3/alice/sw/slc7_x86-64/STARlight/20240617-local1/lib when the real one is with lib64

[sawenzel]

The issue should be fixed by alisw/alidist#5514. Please just use

R__LOAD_LIBRARY(libStarlib.so)
R__ADD_INCLUDE_PATH($STARlight_ROOT/include)

It is better to avoid too many hard-coded paths

[mbroz84]

+async-label async-2023-pbpb-apass4

[chiarazampolli]

Ported to async-v1-01-18, label removed.