Skip to content

Add the possibility of evolving the fit with hoppet - #2485

Open
scarlehoff wants to merge 4 commits into
masterfrom
hippity_hop
Open

Add the possibility of evolving the fit with hoppet#2485
scarlehoff wants to merge 4 commits into
masterfrom
hippity_hop

Conversation

@scarlehoff

@scarlehoff scarlehoff commented Jun 15, 2026

Copy link
Copy Markdown
Member

This PR implements the evolution of the PDF using HOPPET with the --hoppet flag.

The generation of the xgrid, qgrid, etc, is the same as with the vanilla evolution and the results are, at NNLO, equivalent for Q > mc.

For Q < mc the way HOPPET and EKO invert the threshold is different, see:

EKO: https://eko.readthedocs.io/en/latest/theory/Matching.html#backward-evolution
HOPPET: https://github.com/hoppet-code/hoppet/blob/31a2ff92aa82f227505ee0ce111db8acfce340a0/src/evolution.f90#L329

We would need to set inversion_method = expanded and the mass of the charm to 0 to get the exact same results with both.

N3LO to be tested.

@scarlehoff
scarlehoff requested a review from felixhekhorn June 15, 2026 11:47
@scarlehoff
scarlehoff marked this pull request as ready for review June 16, 2026 17:18
@scarlehoff scarlehoff changed the title [WIP] Add the possibility of evolve the code with hoppet Add the possibility of evolve the code with hoppet Jun 16, 2026
@scarlehoff scarlehoff changed the title Add the possibility of evolve the code with hoppet Add the possibility of evolving the fit with hoppet Jun 17, 2026
@scarlehoff
scarlehoff changed the base branch from master to regression_stability June 19, 2026 09:22
Base automatically changed from regression_stability to master June 23, 2026 19:53
eko_path, exportgrids, theory_id
)
else:
# We read the EKO to a temporary directory that will vanish upon exiting

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# We read the EKO to a temporary directory that will vanish upon exiting
# We extract the EKO to a temporary directory that will vanish upon exiting

why is the native EKO.read behaviour not good enough? like with eko.EKO.read

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mh? how is this related to my question here? this is rather the proper issue to this line

# this is a EKO-sized GBs penalty on /tmp, isn't there a get-eko-metadata function??

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, sorry, I'm looking at the comments with my phone, that's the only problem with eko's default behaviour I can remember right now.
I'd need to have a closer look to remember ^^U

wether the fit is hessian
eko_path: str or pathlib.Path
path where the eko is stored (if None the eko will be recomputed)
hoppet: bol

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
hoppet: bol
hoppet: bool

pid_columns = [exportgrid.pids.index(pid) for pid in HOPPET_QCD_PIDS]
pdfgrid = exportgrid.pdfgrid[:, pid_columns]

dispatcher = InterpolatorDispatcher(xgrid, interpolation_degree, mode_N=False)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just remember that you rely on log=True here, which is what you want

qref=nnpdf_theory.Qref,
q0=nnpdf_theory.Q0,
nloop=nloop,
mur_over_q=nnpdf_theory.XIR,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks wrong. Maybe you mean

Suggested change
mur_over_q=nnpdf_theory.XIR,
mur_over_q=nnpdf_theory.XIF,

? Recall that in NNPDF nomenclature the renormalization scale (and hence XIR) refers to the hard scattering, the partonic matrix elements and not to evolution. However, in SV scheme A you shift the evaluation of the strong coupling which multiplies the anomalous dimensions by a factor (see here or the mentioned papers there) and most likely this is what hoppet calls mur_over_q (I haven't check hoppet explicitly). This is because I suspect very much that hoppet can only do scheme A (as with Pegasus for example). Thus at the minimum you need to check the SV scheme here in addition and also match that.

@scarlehoff scarlehoff Aug 18, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should check, probably I read mur and translated it to xir (I only tested central fits so wouldn't see the error in my test)

Comment on lines +91 to +92
if nnpdf_theory.PTO > 2:
raise NotImplementedError("Only up to NNLO for now with hoppet")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, why? hoppet should be able to do N3LO by now, no?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is to be tested! I was waiting for our own 4.1 n3lo fits for that

raise NotImplementedError("Only up to NNLO for now with hoppet")

masses = (nnpdf_theory.mc, nnpdf_theory.mb, nnpdf_theory.mt)
# Note: for hoppet this is both the masses and the thresholds

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we should check they are the same for us, i.e. k=1

# Note: for hoppet this is both the masses and the thresholds

nloop = nnpdf_theory.PTO + 1
fns = nnpdf_theory.FNS.split("-")[0]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this correct? it looks too simple to me (but I haven't checked hoppet). I suspect however, you need either (some variation of) "VFNS" or "FFNS". However, in many cases our FNS should be "FONLL" - which should be mapped to "VFNS".

Comment thread n3fit/src/evolven3fit/hoppet_evolve.py
Comment thread n3fit/src/evolven3fit/hoppet_evolve.py
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants