add sample theorycard for alphas mtop variations at n3lo by RoyStegeman · Pull Request #2349 · NNPDF/nnpdf

RoyStegeman · 2025-07-24T17:46:43Z

This PR adds the theory cards for the alphas, mt variations at aN3LO with EXA evolution and the Moch et al splitting functions.

In total we have

40_013_000 ... 40_013_009 for alphas=0.115, ..., 0.124 at mt = 172.5 GeV
40_014_000 ... 40_014_009 for alphas=0.115, ..., 0.124 at mt = 170.0 GeV
40_015_000 ... 40_015_009 for alphas=0.115, ..., 0.124 at mt = 175.0 GeV

jacoterh · 2025-08-12T14:25:32Z

+TMC: 1
+XIF: 1.0
+XIR: 1.0
+alphaqed: 0.007496252


This value of alphaqed corresponds to scale Qedref=1.777. However, if Qedref is not specified like in this theory card, the scale assumed for alphaqed is taken from Qref, which coincides with the Z pole. But at the Z pole we have alphaqed: 0.0077553, so we should change 0.007496252 to 0.0077553 (or specify Qedref=1.777, but I'm not sure whether this key is supported still)

Sorry for jumping in, but I believe these are all question which I can answer. You have to specify $\alpha_{em}$ and $\alpha_s$ at the same scale if you are doing a joint evolution, i.e. Qedref is no longer supported as it would be inconsistent. However, since you also have QED=0 you are doing QCD only and thus alphaqed is completely ignored I believe. Specifically, it is not used in eko nor yadism nor mg5 (NNPDF/pinefarm#101) nor Matrix (most likely - although that interface is not publicly available 😇 )

Thanks Felix for helping out! We will also do aN3LO + QED at some point, so it's good to know alphaQED and alphas need to be defined at the same scale

jacoterh · 2025-08-12T14:28:28Z

+MP: 0.938
+MW: 80.398
+MZ: 91.1876
+MaxNfPdf: 5


We didn't have MaxNfPdf in theory 40_009_000, is that alright?

this is no longer needed NNPDF/eko#295 (i.e. dropping is the right thing)

jacoterh · 2025-08-12T14:31:50Z

+MaxNfPdf: 5
+ModEv: EXA
+ModSV: null
+NfFF: 4


What is the meaning of the keys NfFF, ModSV, nfref (nr of flavours at the reference scale Q0?), nf0, n3lo_ad_variation, n3lo_cf_variation and use_fhmruvv? I couldn't find these at https://docs.nnpdf.science/theory/theoryparamsdefinitions.html. I can update the website if you tell me :)

If you could update the documentation that would be great 🙈

NfFF basically ignored (it can be used in yadism for a FFNS computation and would specify the number of light flavours there, but in nnpdf we never do FFNS (but FONLL))

ModSV scale variation scheme - since we always use "scheme B" (see old MHOU paper, sec. 3.3), it should be expanded

nfref number of flavours at the couplings reference scale. As Qref is typically $M_Z$ it should be 5

nf0 number of flavours at the fitting scale. As Q0 is typically 1.65 GeV it should be 4

n3lo_ad_variation IHOU variation of the N3LO anomalous dimensions. Order is (gg, gq, qg, qq, nsp, nsm, nsv) Values are 0 or 1 for FHMRUVV and 0..n for in-house (n we would need to dig out somewhere)

n3lo_cf_variation IHOU variations of the N3LO massive DIS coefficient functions. Values are -1, 0, 1 (see here)

use_fhmruvv use N3LO anomalous dimensions by FHMRUVV group instead of in-house? should default to true (after decision at some PC)

NfFF

This then should be updated in the definition of the Theory, which I see was added not only as an important one but even mandatory! (although from the comment it shouldn't be)

nnpdf/nnpdf_data/nnpdf_data/theory.py

Line 32 in aa7cd57

NfFF: int # Number of active flavors, only for FFNS or FFN0 schemes

use_fhmruvv

The decision was not propagated to the repository though:

nnpdf/nnpdf_data/nnpdf_data/theory.py

Line 82 in aa7cd57

use_fhmruvv: Optional[bool] = False

nfref, nf0

These are only needed when you actually want to do something inconsistent. imho it is better to leave them out and let the code decide automatically depending on Q and Q0.

let the code decide automatically

which code? because I think eko does no such thing - they are mandatory there (as we made everything mandatory - one may question that decision, but it is what we have for the moment)

after decision at some PC

just for future reference: I couldn't find any plainly written record of that, but it is clearly stated a Morimondo 2024 blackboard . The corresponding commit in eko is shortly after NNPDF/eko@7735fdb

which code?

The file I linked! A bit below

nnpdf/nnpdf_data/nnpdf_data/theory.py

Line 137 in aa7cd57

def _set_defaults(self):

Ok, thanks, good to know, so for the moment it doesn't hurt to specify these even though it might be redundant. I'll update the documentation! At some point of course we want to remove any redundant keys whenever the code determines these on the fly, but let's see.

jacoterh · 2025-08-12T14:35:58Z

Thanks for this, to answer your question, let's add also the variations at alphas=0.115, 0.117, 0.119, 0.121, 0.122 and 0.123. Probably 0.115 won't be necessary, but better safe than sorry while we're at it. Question: what do we do if our prior on alphas is not centered around the alphas value 0.118 we use in mtop? The obvious thing to do is to regenerate the top FK tables at the new central alphas value, but that's going to be costly...and inefficient. Or maybe the whole point of the TCM is that it doesn't matter as it corrects for it a posteriori!

jacoterh · 2025-08-14T14:52:50Z

@RoyStegeman I've added the alphas and mtop variation theory cards for aN3LO (Moch et al evoln, no QED), please check whether you agree :)

RoyStegeman · 2025-08-14T21:38:07Z

Question: what do we do if our prior on alphas is not centered around the alphas value 0.118 we use in mtop?

I typed a whole reply but should've looked at your commits first... The answer is that I think we should create a set of alphas variations for each mtop value, the EKOs can be reused anyway. Of course, is there is a reason why the alphas dependence of the mtop shifts is negligble at the level of precision we're after, we don't even have to bother with that.

Please update my top comment with an overview of what is in each theory.

jacoterh · 2025-08-15T09:29:10Z

The answer is that I think we should create a set of alphas variations for each mtop value, the EKOs can be reused anyway.

Thanks, I've added also the other alphas variations, see the updated top comment

Please update my top comment with an overview of what is in each theory.

Done

jacoterh · 2025-08-15T14:49:08Z

@felixhekhorn small question: when I generate the EKOs with ModSV set to expanded, I'm getting

XIF is 1.0 while ModSV is expanded. If XIF is equal to 1.0, ModSV should not be defined.

Should I set it to none instead?

felixhekhorn · 2025-08-18T08:11:15Z

@felixhekhorn small question: when I generate the EKOs with ModSV set to expanded, I'm getting

XIF is 1.0 while ModSV is expanded. If XIF is equal to 1.0, ModSV should not be defined.

Should I set it to none instead?

Yes, please - sorry, I was sloppy. The Error is right. (but if you want to do SV, then set it to "expanded")

…litting functs

jacoterh reviewed Aug 12, 2025

View reviewed changes

jacoterh mentioned this pull request Aug 14, 2025

updating docs theory params #2355

Merged

RoyStegeman and others added 8 commits September 12, 2025 11:24

add sample theorycard for alphas mtop variations at n3lo with moch sp…

85cc2e3

…litting functs

Update ID in 40013000.yaml

2c57c76

adding alphas variation theory cards aN3LO Mocht et al

f45c985

adding as variations at mt = 170 and 175 GeV

736b231

updating scalevariationtheoryids.yaml

e6c66a5

putting ModSV to none

28aee12

adding alphas variations 0.125 and 0.126

0bedac4

making ID an int

bd3fb75

jacoterh force-pushed the n3lo_as_mtop_var_theories branch from e6271fb to bd3fb75 Compare September 12, 2025 10:24

scarlehoff closed this Dec 2, 2025

scarlehoff deleted the n3lo_as_mtop_var_theories branch December 2, 2025 13:46

Conversation

RoyStegeman commented Jul 24, 2025 • edited by jacoterh Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacoterh Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

jacoterh commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RoyStegeman commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacoterh commented Aug 15, 2025

Uh oh!

jacoterh commented Aug 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

felixhekhorn commented Aug 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

RoyStegeman commented Jul 24, 2025 •

edited by jacoterh

Loading

jacoterh Aug 12, 2025 •

edited

Loading

jacoterh Aug 13, 2025 •

edited

Loading

jacoterh commented Aug 12, 2025 •

edited

Loading

jacoterh commented Aug 14, 2025 •

edited

Loading

RoyStegeman commented Aug 14, 2025 •

edited

Loading

jacoterh commented Aug 15, 2025 •

edited

Loading