[jaimenorman]

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

[joonsukbae]

Hi @jaimenorman, thanks a lot for the quick PR right after JSUB discussion. The simulation test fails because of the test size. With the default 100 events, gap 9 gives 12 jet-jet events (events 0, 9, ..., 99) and gap 11 gives 10, outside the ±5 % window of the test macros (10.6–11.7 and 8.6–9.5). Gap 7 gives 15 and passes at the edge (13.6–15.0). With a multiple of the gap as the number of test events (98, 99, 99), all three give exactly 1/gap.

[jaimenorman]

Thanks a lot @joonsukbae for spotting this, I have increased the tolerance in the check.
Though the simulation test is now failing for a different reason, looks to be an Alien token that has expired - @sawenzel @jackal1-66 could you check?

[marcovanleeuwen]

Hi @jaimenorman,

It looks like some of the tests ran again. In the build test, there is also a simulation test, which produced an errot and the following output for the gap-11 case:

3-Processing External.C...
4---------------------------------
5-# Events: 100
6-# MB events: 90
7-  sum of weights for MB events: 90
8-# Jet-jet events 10
9-  sum of weights jet-jet events: 2.96859
10-# tracks summed over all events (jet-jet + MB): 68736
11-Number of jet-jet generated events different than expected
12:(int) 1

I think this is a rounding issue: I think that in the current code, the first event is always a JJ events (this may not be the optimal choice, but I am pretty sure that it is what we do), so with 100 events, event 0 and 99 are both jet-jet events, so a total of 10, with 9 expected. (100/11 = 9.09). Shall we increase the limits in the check in the code:

if (nEventsJetJet < nEvents * ratioTrigger * 0.90 || nEventsJetJet > nEvents * ratioTrigger * 1.10) {
        std::cerr << "Number of jet-jet generated events different than expected\n";
        return 1;
    }

Alternatively, could make the calculation more precise by using something like:

nJJExpected = 1 + (nEvents - 1)*ratioTrigger;

which takes into account that the first event is a JJ event.

NB: I think that the generation is sometimes split into subjobs, which can also affect the exact number of events that is generated.

[jaimenorman]

Thanks for spotting this @marcovanleeuwen (indeed gap11 didn't pass the condition), I have increased the tolerance here and the test runs. @jackal1-66 @sawenzel could you check and approve?