Time Like Splitting Functions

[t7phy]

No description provided.

[t7phy]

This PR is almost final and ready to be merged, however there is just one thing left that needs to be checked but I am facing a problem in that once I modify the gamma functions, it seems to me that NUMBA is not recompiling them. How do I force NUMBA to recompile after any change I make?

[alecandido]

This PR is almost final and ready to be merged, however there is just one thing left that needs to be checked but I am facing a problem in that once I modify the gamma functions, it seems to me that NUMBA is not recompiling them. How do I force NUMBA to recompile after any change I make?

Cancel the __pycache__ directories.

https://numba.pydata.org/numba-doc/dev/developer/caching.html#cache-clearing

[t7phy]

This PR is almost final and ready to be merged, however there is just one thing left that needs to be checked but I am facing a problem in that once I modify the gamma functions, it seems to me that NUMBA is not recompiling them. How do I force NUMBA to recompile after any change I make?

Cancel the __pycache__ directories.

https://numba.pydata.org/numba-doc/dev/developer/caching.html#cache-clearing

I actually did delete them in the directory where the as files are stored, however that did not force recompile.

[alecandido]

If you want to just remove Numba cached files, you can filter them with:

find . -type f | grep '\.nb[i|c]$' | xargs rm -f

(.nbi is a cache index file, and .nbc is a pickled Numba object, so a compiled function)

However, this would not fix your problem here:

I actually did delete them in the directory where the as files are stored, however that did not force recompile.

Can you explicitly write exactly which directory you canceled?

[t7phy]

If you want to just remove Numba cached files, you can filter them with:

find . -type f | grep '\.nb[i|c]$' | xargs rm -f

However, this would not fix your problem here:

I actually did delete them in the directory where the as files are stored, however that did not force recompile.

Can you explicitly write exactly which directory you canceled?

eko/src/ekore/anomalous_dimensions/unpolarized/time_like/__pycache__

[alecandido]

eko/src/ekore/anomalous_dimensions/unpolarized/time_like/__pycache__

In principle, it is the correct one. However, try to cancel them all, at least inside anomalous_dimensions.

Worst case solution is of course to reclone the repo in a new location. However, that might work for multiple reasons: Numba objects have to be stored somewhere, but that somewhere might be local, but also non-local to the project (e.g. in case you didn't install EKO in development mode, or if you set Numba to use a global cache).

But, as a first attempt, if deleting is not working, you can try to edit the file you want to recompile. I'm not sure if Numba uses the time-stamp or a file hash, but changing the file content will change both of them.

[t7phy]

eko/src/ekore/anomalous_dimensions/unpolarized/time_like/__pycache__

In principle, it is the correct one. However, try to cancel them all, at least inside anomalous_dimensions.

Worst case solution is of course to reclone the repo in a new location. However, that might work for multiple reasons: Numba objects have to be stored somewhere, but that somewhere might be local, but also non-local to the project (e.g. in case you didn't install EKO in development mode, or if you set Numba to use a global cache).

I had installed in as per documentations for installing EKO for development.

But, as a first attempt, if deleting is not working, you can try to edit the file you want to recompile. I'm not sure if Numba uses the time-stamp or a file hash, but changing the file content will change both of them.

That is indeed the problem. Modifying the file should lead numba to recompile but it is not doing that. Yesterday, I literally deleted the entire content of as2.py and saved it, then I ran NLO benchmarks and they still ran. So something very weird is happening, which I don't understand.

[felixhekhorn]

You may not be responsible for everything, but for the major part yes: please run always pre-commit

We have finally the CI check back! so I can stop complaining personally and let the red cross speak ...

[t7phy]

You may not be responsible for everything, but for the major part yes: please run always pre-commit

We have finally the CI check back! so I can stop complaining personally and let the red cross speak ...

but it has always been active for me. I do not know why it never checked the test files or the doc files, but I have no reason to disable it.

[felixhekhorn]

but it has always been active for me. I do not know why it never checked the test files or the doc files, but I have no reason to disable it.

well, the red cross says something different - and for the fixes in the last two commits and did nothing more then add a random new line somewhere and run pre-commit - so my local version is the CI version ...

in any case I will not attempt the docstyle fixes here to not further spoil this PR, but open a new dedicated one

[t7phy]

but it has always been active for me. I do not know why it never checked the test files or the doc files, but I have no reason to disable it.

well, the red cross says something different - and for the fixes in the last two commits and did nothing more then add a random new line somewhere and run pre-commit - so my local version is the CI version ...

in any case I will not attempt the docstyle fixes here to not further spoil this PR, but open a new dedicated one

So I think everything in this PR is fine now?

[felixhekhorn]

So I think everything in this PR is fine now?

let me run the benchmarks first ... no idea how you managed without 7e325cf and 193afc8 : they are strictly necessary ...

[t7phy]

So I think everything in this PR is fine now?

let me run the benchmarks first ... no idea how you managed without 7e325cf and 193afc8 : they are strictly necessary ...

I ran all benchmarks before the shift was made from Q2 to mu.

[felixhekhorn]

I believe this is ok now

two remarks

• I think this is significant slower than space-like counterparts because here is no reuse of harmonic sums at all (which proves they are a bottleneck) ... the problem can be tackled in Caching harmonic sums #202
• at NNLO V has a bigger error O(0.2%) than S O(0.04%) in the small x region (where small here x=0.01) which is a bit odd, but fine

[alecandido]

After isolated benchmarks completion feel free to merge. Problems with pre-commit are not caused by this PR.