Decorrelate N3LO IHOU by jekoorn · Pull Request #388 · NNPDF/yadism

jekoorn · 2026-08-12T09:34:25Z

Closes #328

n3lo_cf_variation seems to be a single number, although I believe it should be 4 numbers: (C2g, C2q, CLg, CLq), i.e. one per coefficient we want to vary

jekoorn · 2026-08-12T09:37:51Z

currently it looks like the light coefficient functions support no variation at all, e.g. looking at https://github.com/NNPDF/yadism/blob/master/src/yadism/coefficient_functions/light/kernels.py#L78 vs https://github.com/NNPDF/yadism/blob/master/src/yadism/coefficient_functions/heavy/kernels.py#L76 . do we want to implement this as well at the same time?

juanrojochacon · 2026-08-12T09:41:21Z

currently it looks like the light coefficient functions support no variation at all, e.g. looking at https://github.com/NNPDF/yadism/blob/master/src/yadism/coefficient_functions/light/kernels.py#L78 vs https://github.com/NNPDF/yadism/blob/master/src/yadism/coefficient_functions/heavy/kernels.py#L76 . do we want to implement this as well at the same time?

@jekoorn the light coefficient functions at N3LO are known exactly so no, they should not be varied in any way. IHOUs are only required for the N3LO massive coefficient functions

jekoorn · 2026-08-12T12:51:50Z

How does the code distinguish between whether an FL or F2 component is called? I don't really see how I should tell the code to use C2g vs CLg

juanrojochacon · 2026-08-12T13:10:50Z

Felix will confirm, but I think that the distinction is made through

kind = esf.info.obs_name.kind at the top of generate, which is then used in import_pc_module(kind, esf.process). So indeed it is ok that you don't see the distinction there

felixhekhorn · 2026-08-12T13:12:44Z

Please remember to resolve the conversations, which you believe to have addressed

felixhekhorn · 2026-08-12T13:14:39Z

Also please don't code only in the void - at some point you need to actually run locally yourself! this is to say: you still have syntax errors

jekoorn · 2026-08-12T13:58:27Z

Also please don't code only in the void

yeah sorry for the mess, my editor didn't catch the syntax errors for some reason. I am apparently rusty after the holidays🙃

Another question: Do we only require a variation in the case that we evaluate F2 and FL? Not the others? (Are they known already?)
And if so, I think with the if/else statements it's a bit messy. But it looks like the other components don't use it, so it doesn't matter what we pass.

juanrojochacon · 2026-08-12T14:00:54Z

yes, only F2 and FL, xF3 is not relevant here

felixhekhorn

Let me ask again: have you actually run this code? and check e.g. that when you put different numbers this is propagated down to adani correctly?

jekoorn · 2026-08-18T09:31:58Z

have you actually run this code?

I am currently checking this with pinefarm (since I have to generate grids anyway and needed a pipeline). But probably it's easier to do this with yadism standalone 🙈

jekoorn · 2026-08-18T10:00:29Z

There are still some NaNs spawning, apparently. I will investigate this..
A fresh yadism also gets NaNs though, so I am not sure to what extent the NaNs are "supposed" to be there or not..

Radonirinaunimi · 2026-08-20T06:37:00Z

There are still some NaNs spawning, apparently. I will investigate this.. A fresh yadism also gets NaNs though, so I am not sure to what extent the NaNs are "supposed" to be there or not..

Could you please provide more details (which cards are you using, do the NaNs appear for specific processes/datasets/variations, etc.)? There are some NaNs that are fine (such as at very low $Q^2$) and there are some that are dangerous. From the recent grid computations, the latter should no longer appear.

jekoorn · 2026-08-20T09:02:44Z

Could you please provide more details (which cards are you using, do the NaNs appear for specific processes/datasets/variations, etc.)?

Sure!
For checking whether the variations produce different outputs, instead of using cards, I am using my own script that computes the structure functions. Just electron-proton collision at 1TeV.
I am integrating $Q^2$ from as low as 2.0, and x > 1e-6. I am using the theory cards from NNPDF/nnpdf#2494 but with the CF variations put in.
The broader issue is here that the outputs from different variations still yield the exact same output. I am wondering now if the setup I use for checking this is actually sufficient.
See https://vp.nnpdf.science/nVd3gBnfT2S-psG9B5g5gQ==/ for the script
Probably a good check would be whether running with actual pinecards yields NaNs, but for now I wanted to check whether the CF variations do what they are supposed to.

felixhekhorn · 2026-08-24T11:50:38Z

The broader issue is here that the outputs from different variations still yield the exact same output.

I suggest to put a debugger (or print or whatever) here

yadism/src/yadism/coefficient_functions/heavy/f2_nc.py

Line 49 in 467615f

"C2g", nf=self.nf, variation=self.n3lo_cf_variation

and check what variation arrives there and then what you get back

Also do you get finite numbers with the default settings? i.e. without any variation? so we know the problem is with the variations (and not with something else)

jekoorn · 2026-08-25T12:05:35Z

put a debugger (or print or whatever) here

nothing looks to arrive there, with whatever variation I put in. Probably explains why the calculations yield the same result between different variations. It makes me doubt whether the correlated variations were even doing what they should in the first place, before starting this implementation.

With default settings I also get NaNs, but to be precise: they don't appear in the output, it's just a notification that the runner passes:

 took 6.43 s
[14:03:10] CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!

Radonirinaunimi · 2026-08-25T12:18:08Z

put a debugger (or print or whatever) here

nothing looks to arrive there, with whatever variation I put in. Probably explains why the calculations yield the same result between different variations. It makes me doubt whether the correlated variations were even doing what they should in the first place, before starting this implementation.

With default settings I also get NaNs, but to be precise: they don't appear in the output, it's just a notification that the runner passes:
 took 6.43 s
[14:03:10] CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!                                                                                                                                                         runner.py:224
           CRITICAL Some NaNs are encountered and set to zero!

These NaNs are fine (as I per above) so you shouldn't worry about those. They are in the regions where pQCD breaks down and these warnings are just there warn people that these regions are probed.

felixhekhorn · 2026-08-25T12:31:56Z

They are in the regions where pQCD breaks down and these warnings are just there warn people that these regions are probed.

@Radonirinaunimi I think you put these warnings there in the first place, right? so you know that they are in this region? because this can not be inferred from the output ... (i.e. if we have the kinematics in hand there it might be good to echo them alongside 🙃 )

nothing looks to arrive there, with whatever variation I put in. Probably explains why the calculations yield the same result between different variations. It makes me doubt whether the correlated variations were even doing what they should in the first place, before starting this implementation.

@jekoorn then a) you should check on master what you get there (and confirm or reject your doubts) and b) then you "just" need to trace their way back and e.g. check what you get immediately inside yadism = in the runner e.g. here

yadism/src/yadism/runner.py

Line 127 in 17a6c55

if isinstance(theory["n3lo_cf_variation"], int):

jekoorn · 2026-08-25T12:35:54Z

on it @felixhekhorn

Radonirinaunimi · 2026-08-25T13:03:13Z

@Radonirinaunimi I think you put these warnings there in the first place, right? so you know that they are in this region? because this can not be inferred from the output ... (i.e. if we have the kinematics in hand there it might be good to echo them alongside 🙃 )

Yes, I agree. I should have printed out the kinematics alongside for full transparency and certainty. Since we are at it, I would suggest to add this in this PR.

jekoorn · 2026-08-25T15:10:56Z

For debugging purposes, which FNS should I use? In some cases the code simply breaks, which probably has to do with not choosing the appropriate nf, in combination with the FNS. At least the variations look like they're activated with the FFN0 scheme.
Maybe in the end, seeing what happens with a full pinefarm run is best after all.

felixhekhorn · 2026-08-25T15:39:25Z

For debugging purposes, which FNS should I use?

I suggest FFNS3, so FNS: FFNS + NfFF: 3 (check that you actually pass by where you want). FFN0 would work as well and you would just end up then on the asy side. Then later in the real world we should also test full FONLL (which is a combination of FFNS and FFN0).

Maybe in the end, seeing what happens with a full pinefarm run is best after all.

This would be (very likely) directly the FONLL case. However, since FONLL has multiple ingredients that might make debugging more complicated ... but actually, you could also just use the correct FFNS theory card there (courtesy of NNPDF/nnpdf#2498)

jekoorn · 2026-08-27T08:19:46Z

This exact FFNS theory card with FFNS3 fails, for some reason. Also on the master branch without the n3lo_cf_variation : [0,0,0,0], with the same error. See here

 • F2_charm at 1 pts

                                                                                                                       Calculation
yadism took off! please stay tuned ...
a heavy vv gluon is made, with variation -1
Traceback (most recent call last):
  File "/data/theorie/jkoorn/git/yad-4ihou/run.py", line 150, in <module>
    F2_tot, FL, F2_c, FL_c = runner(
                             ~~~~~~^
        Ebeam=1000,
        ^^^^^^^^^^^
    ...<6 lines>...
        theory_path=f"/data/theorie/jkoorn/git/yad-4ihou/{theory}.yaml"
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/data/theorie/jkoorn/git/yad-4ihou/run.py", line 135, in runner
    F2_c = compute_observable("F2_charm", xgrid, Q2grid, Ebeam, PTO, channel, particle, target,runningscales, PDF, theory_path)
  File "/data/theorie/jkoorn/git/yad-4ihou/run.py", line 77, in compute_observable
    output = yadism.run_yadism(theory, observable)
  File "/data/theorie/jkoorn/git/yad-4ihou/src/yadism/__init__.py", line 31, in run_yadism
    return runner.get_result()
           ~~~~~~~~~~~~~~~~~^^
  File "/data/theorie/jkoorn/git/yad-4ihou/src/yadism/runner.py", line 292, in get_result
    results[idx] = elem.get_result()
                   ~~~~~~~~~~~~~~~^^
  File "/data/theorie/jkoorn/git/yad-4ihou/src/yadism/esf/esf.py", line 189, in get_result
    self.compute_local()
    ~~~~~~~~~~~~~~~~~~^^
  File "/data/theorie/jkoorn/git/yad-4ihou/src/yadism/esf/esf.py", line 143, in compute_local
    val, err = conv.convolve_vector(
               ~~~~~~~~~~~~~~~~~~~~^
        rsl, self.info.configs.managers["interpolator"], convolution_point
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/data/theorie/jkoorn/git/yad-4ihou/src/yadism/esf/conv.py", line 230, in convolve_vector
    c, e = convolution(cf, convolution_point, polynomial_f)
           ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/theorie/jkoorn/git/yad-4ihou/src/yadism/esf/conv.py", line 151, in convolution
    res, err = scipy.integrate.quad(
               ~~~~~~~~~~~~~~~~~~~~^
        quad_ker,
        ^^^^^^^^^
    ...<4 lines>...
        points=breakpoints,
        ^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/data/theorie/jkoorn/miniconda/envs/yadism-d/lib/python3.13/site-packages/scipy/integrate/_quadpack_py.py", line 479, in quad
    retval = _quad(func, a, b, args, full_output, epsabs, epsrel, limit,
                   points)
  File "/data/theorie/jkoorn/miniconda/envs/yadism-d/lib/python3.13/site-packages/scipy/integrate/_quadpack_py.py", line 639, in _quad
    return _quadpack._qagpe(func, a, b, the_points, args, full_output,
           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                            epsabs, epsrel, limit)
                            ^^^^^^^^^^^^^^^^^^^^^^
TypeError: only 0-dimensional arrays can be converted to Python scalars

If you have an idea what is going wrong here I would be very happy to continue working on this but I think I am currently too lost by which FNS's work and which don't 😅

At least I'venow verified that the correct variations are passed to the correct places, so at least the original goal of this test has been succesful!

felixhekhorn · 2026-08-27T11:06:44Z

ehm, I'm confused, because I have seen numbers from @evagroenendijk supposedly using that card - @evagroenendijk can you please confirm?

That being said, the error sounds more like a local problem: are you sure your runcards are 100% correct? the question is in particular for the types: are things which should be a scalar number just that and not some array? (For dumping runcards to file even np.float vs. Python float makes a difference, but I think that should not be a problem here.) However, doing remote debugging is tricky 🙃 ... actually, the type mismatch might also be at the bottom (so where we are interested in).

At least I'venow verified that the correct variations are passed to the correct places, so at least the original goal of this test has been succesful!

a good thing for sure, but you know people (meaning Juan 🙈 ) want to see the real deal

jekoorn · 2026-08-27T11:17:50Z

However, doing remote debugging is tricky 🙃

I understand, of course, but since it's apparently an issue that only pops up with some FNS's (code runs fine under ZM-VFNS), I was hoping...

But if @evagroenendijk has a runscript with this card that works, so much the better!

evagroenendijk · 2026-08-27T11:35:46Z

@jekoorn @felixhekhorn Indeed I use exactly that theory card and it works fine. I think it's a compatibility issue between numpy and the scipy integration. I reproduce your error when using numpy v2.4, I myself was using v2.2.6 and then it does work (I think v2.4 numpy outputs an array somewhere while v2.2.6 outputs a value)

felixhekhorn · 2026-08-27T12:00:45Z

I think it's a compatibility issue between numpy and the scipy integration

ooh, you are saying this is a side effect of our Python (and dependencies) upgrade ... in particular #383

Okay, so we need to sort that out. I would suggest to solve this issue first (starting from master branch) and then rebase/merge this one on top afterwards so the two things get disentangled.

Sigh... if only yadism would have some sort of benchmarks, e.g. here #162 or also just in pinefarm, which would run on a regular basis and where we would detect such problems ...

jekoorn · 2026-08-27T12:17:44Z

Okay, so we need to sort that out.

Will be addressed in #389

felixhekhorn · 2026-08-28T12:13:53Z

then rebase/merge this one on top afterwards

please still check explicitly that you get different numbers for different variations (and they are not crazy different)

jekoorn · 2026-08-28T12:48:33Z

Differences are in the 10-30% range when comparing the correlated vs uncorrelated min/max variations - typically the uncorrelated variations (squares summed) are slightly smaller. I'm thinking about how to properly present the results, but I can just link a file with a plaintext table that I made using pineappl diff.
Btw, all using Eva's nice benchmark runcards.

felixhekhorn · 2026-09-04T12:53:20Z

Differences are in the 10-30% range when comparing the correlated vs uncorrelated min/max variations

Can we be a bit more specific? for which observable? for which kinematics? we are talking only about the N3LO corrections (and not the full thing), right?

I'm thinking about how to properly present the results, but I can just link a file with a plaintext table that I made using pineappl diff.

If you can come up quickly with some clever representation, fine, else also plain text files will do for now. Then for the 4.1 paper we need to do something more clever 🙃

jekoorn · 2026-09-04T13:03:30Z

for which observable? for which kinematics?

In this case, I used Eva's runcards for the N3LO benchmark to compute F2C and FLC. To get the N3LO corrections, should I just subtract the NNLO component? And do these observables suffice, or do we want an actual cross-section in the end?

felixhekhorn · 2026-09-04T13:35:08Z

In this case, I used Eva's runcards for the N3LO benchmark to compute F2C and FLC.

in principle fine, but we need to remember, that some of the kinematics are just unreachable by HERA

And do these observables suffice, or do we want an actual cross-section in the end?

thus, it might make also sense to look at the true settings as well. We can start with the easy thing first (just F2+FL). For the paper we need the real thing.

To get the N3LO corrections, should I just subtract the NNLO component?

Yes. Also PineAPPL can do it directly (I think). Both things (total and relative) are interesting.

jekoorn requested review from felixhekhorn and juanrojochacon August 12, 2026 09:34

felixhekhorn added bug Something isn't working enhancement New feature or request labels Aug 12, 2026

jekoorn self-assigned this Aug 12, 2026

felixhekhorn reviewed Aug 12, 2026

View reviewed changes

Comment thread src/yadism/runner.py Outdated

felixhekhorn reviewed Aug 12, 2026

View reviewed changes

Comment thread src/yadism/runner.py Outdated

felixhekhorn reviewed Aug 12, 2026

View reviewed changes

Comment thread src/yadism/runner.py Outdated

felixhekhorn reviewed Aug 12, 2026

View reviewed changes

Comment thread src/yadism/coefficient_functions/heavy/kernels.py

felixhekhorn reviewed Aug 13, 2026

View reviewed changes

Comment thread src/yadism/coefficient_functions/asy/kernels.py Outdated

felixhekhorn reviewed Aug 13, 2026

View reviewed changes

Comment thread src/yadism/runner.py

felixhekhorn requested changes Aug 18, 2026

View reviewed changes

Comment thread src/yadism/coefficient_functions/asy/kernels.py Outdated

Comment thread tests/yadism/cf/test_nc_kernels.py Outdated

Radonirinaunimi reviewed Aug 25, 2026

View reviewed changes

Comment thread src/yadism/runner.py Outdated

felixhekhorn reviewed Aug 25, 2026

View reviewed changes

Comment thread src/yadism/runner.py Outdated

felixhekhorn changed the title ~~N3LO IHOU are correlated~~ Decorrelate N3LO IHOU Aug 28, 2026

jekoorn and others added 12 commits August 28, 2026 14:22

initial commit, add cf vars for heavy cfs

a534df9

replace dict by tuple

5e68883

add backwards comp., differentiate FL and F2 components

6d1b42a

fix syntax

964a61b

fix syntax again

c87d1dc

remove else

8980754

bug fixes, updated test to use tuple

5226f9f

changed asy/kernels.py like heavy

8e17e5a

use correct variation, fixed typo in tests

9c87109

print kinematics alongside NaN message

e977294

also write Q2

4db038b

Remove added empty line

df5f86f

jekoorn force-pushed the 4ihou branch from 7e81ad6 to df5f86f Compare August 28, 2026 12:23

Uh oh!

Conversation

jekoorn commented Aug 12, 2026 • edited by felixhekhorn Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jekoorn commented Aug 12, 2026

Uh oh!

Uh oh!

Uh oh!

juanrojochacon commented Aug 12, 2026

Uh oh!

jekoorn commented Aug 12, 2026

Uh oh!

Uh oh!

juanrojochacon commented Aug 12, 2026

Uh oh!

Uh oh!

felixhekhorn commented Aug 12, 2026

Uh oh!

felixhekhorn commented Aug 12, 2026

Uh oh!

jekoorn commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juanrojochacon commented Aug 12, 2026

Uh oh!

Uh oh!

Uh oh!

felixhekhorn left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jekoorn commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jekoorn commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Radonirinaunimi commented Aug 20, 2026

Uh oh!

jekoorn commented Aug 20, 2026

Uh oh!

felixhekhorn commented Aug 24, 2026

Uh oh!

jekoorn commented Aug 25, 2026

Uh oh!

Radonirinaunimi commented Aug 25, 2026

Uh oh!

felixhekhorn commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jekoorn commented Aug 25, 2026

Uh oh!

Radonirinaunimi commented Aug 25, 2026

Uh oh!

Uh oh!

jekoorn commented Aug 25, 2026

Uh oh!

felixhekhorn commented Aug 25, 2026

Uh oh!

Uh oh!

jekoorn commented Aug 27, 2026

Uh oh!

felixhekhorn commented Aug 27, 2026

Uh oh!

jekoorn commented Aug 27, 2026

Uh oh!

evagroenendijk commented Aug 27, 2026

Uh oh!

felixhekhorn commented Aug 27, 2026

Uh oh!

jekoorn commented Aug 27, 2026

Uh oh!

felixhekhorn commented Aug 28, 2026

Uh oh!

jekoorn commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

felixhekhorn commented Sep 4, 2026

jekoorn commented Aug 12, 2026 •

edited by felixhekhorn

Loading

jekoorn commented Aug 12, 2026 •

edited

Loading

jekoorn commented Aug 18, 2026 •

edited

Loading

jekoorn commented Aug 18, 2026 •

edited

Loading

felixhekhorn commented Aug 25, 2026 •

edited

Loading

jekoorn commented Aug 28, 2026 •

edited

Loading