Update tune from SCCR to QCDCR for pO and OO

[wuctlby]

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

[wuctlby]

Dear @jackal1-66 , could you please have a look at what causes the test errors? The error messages are not super clear to me. Thanks a lot!

[wuctlby]

Besides, the grid test with the same cfg and ini files is successful. I just put the link here https://alimonitor.cern.ch/catalogue/?path=%2Falice%2Fcern.ch%2Fuser%2Fc%2Fchuntai%2F%2FMC_production%2Fnew_OO%2Ftest_10k_OO_qcd_test-20260201-154720

[jackal1-66]

Ciao @wuctlby , something seems to be wrong on the framework side. I'm investigating what the problem might be

[jackal1-66]

I couldn't find anything clear in the framework. Other generators and tests seem to be working fine. @wuctlby could you please check that the replaceParticle function logic is working as expected? The issue seems to be triggered there. I would look also in the correct cycling over the iPart variable. I'm investigating why this works for specific tags (until 28 of January it seems) and it's broken in more recent ones. I'm asking the experts (@ktf) also if something minor has changed that could trigger the memory fault somehow. Pythia doesn't seem to be the issue (last version is from 8 months ago).

[wuctlby]

Ciao @jackal1-66 , thanks a lot for the checks. I will follow your suggestion and check it.

[wuctlby]

Hi @jackal1-66 , I submitted another PR #2258 for the test, while it's still failed. And the log shows it ends after this test ++ /sw/slc9_x86-64/O2DPG/2258-slc9_x86-64-local1/test/run_generator_tests.sh. So I tested it locally, the ouputs are listed below:

[O2/latest O2DPG/latest-master-o2] ~/alice/O2DPG/test $> bash run_generator_tests.sh 

################################
# Run O2DPG simulation testing #
################################

Following INI files will be tested:
  - /home/wuct/alice/O2DPG/MC/config/PWGHF/ini/GeneratorHF_D2H_ccbar_and_bbbar_gap2_QCDCR_OO.ini
  - /home/wuct/alice/O2DPG/MC/config/PWGHF/ini/GeneratorHF_D2H_ccbar_and_bbbar_gap2_QCDCR_pO.ini
Checking /home/wuct/alice/O2DPG/MC/config/PWGHF/ini/GeneratorHF_D2H_ccbar_and_bbbar_gap2_QCDCR_OO.ini
Test 0: /home/wuct/alice/O2DPG/MC/config/PWGHF/ini/GeneratorHF_D2H_ccbar_and_bbbar_gap2_QCDCR_OO.ini with generator External -> PASSED
Checking /home/wuct/alice/O2DPG/MC/config/PWGHF/ini/GeneratorHF_D2H_ccbar_and_bbbar_gap2_QCDCR_pO.ini
Test 1: /home/wuct/alice/O2DPG/MC/config/PWGHF/ini/GeneratorHF_D2H_ccbar_and_bbbar_gap2_QCDCR_pO.ini with generator External -> PASSED

All generator tests successful

It seems to be successful, but there are some warnings, such as [09:25:19][WARN] Particle to be tracked is not defined in PDG: pdg = 1000000069 (disabling tracking). In my opinion, this should not affect the final test result.

[jackal1-66]

Ciao @wuctlby , I also tested it locally with a more recent tag and it fails. I had luck with the cvmfs daily tag of the 28 of January, but something seems wrong.

[wuctlby]

Ciao @wuctlby , I also tested it locally with a more recent tag and it fails. I had luck with the cvmfs daily tag of the 28 of January, but something seems wrong.

Okay, I would rebuild the whole framework with the lastest tag, and let' see. Besides, I also had a look at the replaceParticle function. In princelple, it should not be triggered for these OO and pO cases.

[jackal1-66]

Found the issue, it's unrelated to your PR. I'll prepare a fix

[wuctlby]

Hi @jackal1-66 , thanks! I also reran the test and simulation, and both failed for the recent tag, just as you said. Now, I see your point. At the beginning, the log shows the error triggered by event::particle::daughterList(), then I further checked what happens in the event. I got a similar case basically from all ini files:

Starting event selection loop over 18446744073381051457 particles 
==> may lead to Timeout
// or //
[3172521:generator-task]: [21:03:34][INFO] WUCT Starting event selection loop over 1003143265 particles
[3172521:generator-task]: [21:03:34][INFO] WUCT iPart: 0
[3172521:generator-task]: [21:03:34][INFO] WUCT Checking for parton level trigger
[3172521:generator-task]: [21:03:34][INFO] WUCT event size: 1003143265
[3172521:generator-task]: *** Program crashed (Segmentation fault)
[3172521:generator-task]: Backtrace by DPL:

Obviously, it's impossible we have such a lot of particles in a single event. And in some cases, the size obviously doesn't match the particle number shown in the Particle Data Table.

I see your pr is still in review, and hope these infomation can help.