nnpdf
nnpdf copied to clipboard
Update PineAPPL version to `v1`
For the time being, this is primarily needed because pineko (https://github.com/NNPDF/pineko/pull/206) depends on it. This does not introduce physic's changes yet, ie still does not allow for an arbitrary number of convolutions.
sorry, wouldn't it be better to instead of having a branch here just for the pineko dev branch, to remove for now nnpdf from the pineko dev branch?
Or do you need nnpdf there?
sorry, wouldn't it be better to instead of having a branch here just for the pineko dev branch, to remove for now nnpdf from the pineko dev branch?
Or do you need nnpdf there?
Yes, nnpdf would be needed there, not only for some tests (which I'd like all of them to pass) but also to fully test that the evolution pipeline is working perfect. But also, as soon as v1 is available, we'll need to upgrade asap anyway in order to get rid of the reliance on the PineAPPL metadata (and ofc a bit later on to generalize to arbitrary convolution).
ok then! I've left some small comments, although it is WIP I thought better to mention these small points sooner rather than later.
Thanks for the comments @scarlehoff!
Just one question, in principle old fktables we will always be able to read, right?
Yes, old FK tables will still be read as before perfectly. The only difference is that now when PineAPPL reads these FK tables it'll add onto them the new attributes (for e.g. convolutions) .
As of 1.0.0a4 there's a problem with fktables that include bins that are 0. It is possible to still fits simply by removing these 0 points as they are also ignored by the nnpdf code:
#!/usr/bin/bash
for i in *.lz4
do
if ! python -c "import pineappl ; pineappl.fk_table.FkTable.read(\"${i}\").table()" 2>/dev/null
then
echo "Removing extra points from" $i
bins=$(pineappl read ${i} --bins | awk 'END{print $1}')
pineappl write ${i} --delete-bins 1-${bins} tmp.lz4
mv tmp.lz4 ${i}
fi
done
This needs to be rebased to ensure that everything works.
I would say let's ignore here the fact that pineappl>=1.0 is not compatible with eko>=0.15 since they never need to talk for this repo (it is only a problem for pineko, but pineko depends only on nnpdf-data not in the full nnpdf)
How is PineAPPL incompatible with EKO?
It was mentioned in the last code meeting, but I don't know the details.
Probably that's off-topic, but I just wanted to mention that with pineappl v1, we need to update the API extension notebook too. I was thinking that this branch might be the most appropriate place to update it. I can take care of that if you don't mind.
Probably that's off-topic, but I just wanted to mention that with pineappl v1, we need to update the API extension notebook too. I was thinking that this branch might be the most appropriate place to update it. I can take care of that if you don't mind.
Yes, sure.
PS: There isn't a conda version of v1 yet so for the time being please just ignore the failing tests.
If you could update this as well https://github.com/NNPDF/nnpdf/blob/master/validphys2/examples/API_extension_Pineappl.ipynb before merging that would be great. Otherwise I can have a go tomorrow or the day after and merge it then.
Greetings from your nice fit :robot: ! I have good news for you, I just finished my tasks:
- Fit Name: NNBOT-f660083ff-2025-06-11
- Fit Report wrt master: https://vp.nnpdf.science/vPn4n-XTQKWSkV_6ZDUChA==
- Fit Report wrt latest stable reference: https://vp.nnpdf.science/9EuAnAblSBCz1PTLTl1sdQ==
- Fit Data: https://data.nnpdf.science/fits/NNBOT-f660083ff-2025-06-11.tar.gz
Check the report carefully, and please buy me a :coffee: , or better, a GPU :wink:!