Rustify ekore part 2: ad.u.s.{as2,as3}

[felixhekhorn]

Actually, we should push for the continued rustification before @giacomomagni receives his halo and someone else has to translate all those endless N3LO expression. I will not attempt the full rustification here but still proceed in parts (i.e. this is part 2 (after #189 ) out of X): currently my only goal here is to be ready for QCD N3LO ad. To be specific:

ekore/anomalous_dimensions/unpolarized/space_like/

• as2.py
• as3.py

[giacomomagni]

Thanks @felixhekhorn
I'm not sure if I'll be able to contribute to this endeavour at some point

[tgiani]

@felixhekhorn when you have time could you please have a look at as2.rs? It should be mostly done. I have not implemented the tests with NC=4 because I don t see how to change a const in rust, not sure if that can be done? If there are no major issues with what done in as2.rs I can proceed with as3.py

Edit: actually the qed stuff is not there. Should I add that as well or for the time being we go for qcd only?

[felixhekhorn]

for the time being we go for qcd only

indeed - let's proceed in parts and first we do QCD only

One simple comment up front: please run pre-commit

[felixhekhorn]

• I think the NC=4 case is artificial and we simply don't allow for this hypothetical feature any longer
• of course we eventually have to hook the function in on the higher level

[felixhekhorn]

(now somehow cargo fmt is broken for me and I don't know why since it was working fine the whole afternoon, so I might have broken pre-commit myself, but I will try to fix this tomorrow)

* of course we eventually have to hook the function in on the higher level

8c304b8 should have done this

However, there seems to be something fishy: if you rustify and then run poe lha -m "ffns and nlo and not sv" you will see that V, V3 and T3 are completely off (by ~5%)

[tgiani]

mm ok. I guess by rustify you mean running the script rustify.sh?

[felixhekhorn]

mm ok. I guess by rustify you mean running the script rustify.sh?

exactly - this will hook the Rust backend into the main eko package + remember to actually compile via poe compile; this way we can run the usual eko workflows (with the limited available orders of course) e.g. to check against the LHA benchmark number which we will have to reproduce ...

[tgiani]

ok I see. Other question: isn t pytest installed automatically in the poetry venv when I run poetry install?
If I do poetry install, rustify, poe compile and then poe lha -m "ffns and nlo and not sv" it doesn t find pytest

[felixhekhorn]

ok I see. Other question: isn t pytest installed automatically in the poetry venv when I run poetry install? If I do poetry install, rustify, poe compile and then poe lha -m "ffns and nlo and not sv" it doesn t find pytest

no, since it is a developer dependency - you can do poetry install --with test (Poetry has this dependency groups)

[felixhekhorn]

now somehow cargo fmt is broken for me and I don't know why since it was working fine the whole afternoon, so I might have broken pre-commit myself, but I will try to fix this tomorrow

okay, so it turns out that it was just a veeery long run for cargo fmt, but eventually it does terminate - as a fix I inserted a bunch of #[rustfmt::skip] - not all of them are actually required, but mostly the ones for the long expressions. However, then for consistency I put them all. In the end the expressions are just math and there is no big insight in having them formatted (although they are easier to check this way). What do you think @tgiani? should we keep the markers?

[tgiani]

yea I think so else every time we commit we have to wait half an hour

[tgiani]

I m trying to run the benchmark poe lha -m "ffns and nlo and not sv" to investigate the problem you mentioned yesterday but that also has been run for several minutes now. Do you know how long it is supposed to take?

[felixhekhorn]

I m trying to run the benchmark poe lha -m "ffns and nlo and not sv" to investigate the problem you mentioned yesterday but that also has been run for several minutes now. Do you know how long it is supposed to take?

Ehm, yes this is a feature 🙃 (one that we are trying to partly tackle here) for the first run eko will take a while, because it needs to compile all the numba stuff, which is a lot. Normally it can take up to 15 min if the OME are involved, but actually here it should be quicker, since we're running FFNS and poe compile already did part of the work. You can check if numba is the problem by setting NUMBA_DEBUG or you can set EKO_LOG_STDOUT to check what EKO is doing.

PS: the second run is ~10s for me

[tgiani]

Ehm, yes this is a feature 🙃 (one that we are trying to partly tackle here) for the first run eko will take a while, because it needs to compile all the numba stuff, which is a lot. Normally it can take up to 15 min if the OME are involved, but actually here it should be quicker, since we're running FFNS and poe compile already did part of the work. You can check if numba is the problem by setting NUMBA_DEBUG or you can set EKO_LOG_STDOUT to check what EKO is doing.

PS: the second run is ~10s for me

ok after 30 min I ve stopped it and I m trying again setting the two env variables you suggested. Is the singlet sector alright from the benchmark? If so the problem should be something in gamma_nsm no?

[felixhekhorn]

ok after 30 min I ve stopped it and I m trying again setting the two env variables you suggested. Is the singlet sector alright from the benchmark? If so the problem should be something in gamma_nsm no?

Mmm not sure ... in the singlet sector we match my 0.4% and I'm not sure if that is good enough (LO we match by 0.02%) and we should check with master. I also see that T8 and T15 are kind of okay, but T3 is not - and all should be NS+ ... Of course T3 is small in absolute value, so maybe there is some precision loss somewhere?

[tgiani]

mm i don t know... In the expressions I m doing the following replacements:

• I turn all integers except those in exponents into floats (else algebra with complex is not defined)
• np.power(N,integer)->N.powu(integer)
• np.pi**2 -> PI.pow(2)
• NF -> (NF as f64)

does any of this seem wrong?

[tgiani]

anyway I m still stuck on this poe lha -m "ffns and nlo and not sv". Since about 1hr 30 min the last log I get from numba is

================================================================================
-------------------------OPTIMIZED DUMP cb_quad_ker_qcd-------------------------
; ModuleID = 'cb_quad_ker_qcd'
source_filename = "<string>"
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-darwin23.4.0"

================================================================================
================================================================================
----------------------------ASSEMBLY cb_quad_ker_qcd----------------------------
        .section        __TEXT,__text,regular,pure_instructions
        .build_version macos, 14, 0
.subsections_via_symbols

================================================================================

not sure what the problem here

[felixhekhorn]

c11f6c4 fixes a stupid typo which was preventing us from passing the benchmark - now we are passing as before. If there are no complaints I will merge this tomorrow.

@tgiani c11f6c4 also added an explicit nopython argument to the function which is passed through Rust - this should already be the default (this changed in numba 0.59), but can you please check nevertheless that you still have the same exception?

[tgiani]

@felixhekhorn ah ok good. Yes also after your last commit I still have the same problem on mac

[felixhekhorn]

Continuing from here we can have several parallel parts:

1. ome.u.s.as1 and ome.u.s.as2 + VFNS
2. recover SV
3. ad.p.s.*
4. recover solution methods
5. ad.u.s.as4 and ad.u.s.as4.fhmruvv
6. ad.u.s.*aem* + QED
7. ad.u.t.*
8. ome.u.s.as4
9. anything left

The order of the list is a slight indication of priority. Not every item needs a separate PR although that might help in the review. In case you are not tired yet @tgiani pick your favourite!

EDIT: see #383

[tgiani]

sure, I guess I ll start from 1. What s 2?

[felixhekhorn]

What s 2?

actually quite simple:

eko/src/eko/evolution_operator/quad_ker.py

Line 107 in 2348778

sv_mode = sv.Modes.exponentiated

replace the hardcoded value by reading from _sv_mode_num and put that parameter to a sensible value in the first place

eko/src/eko/evolution_operator/__init__.py.patch

Line 625 in 2348778

+ cfg.sv_mode_num = 1

the same holds for item 4 (e.g. they could go in one PR)