Use the NNPDF data instead of yamldb#159
Conversation
andreab1997
left a comment
There was a problem hiding this comment.
Ok I see and it is fine for me.
I see that this is a proof of concept, but are you planning to do the full job here? In other words, should I take care of this?
|
Nono, I will. I just wanted to know whether you were ok with the approach. I hope to merge tomorrow this NNPDF/nnpdf#1965 so I will finish it when that's in. |
|
This would have the advantage of being able to read the kinematics from there, |
04ffec3 to
268d2d4
Compare
|
This is ready for review (and modifications) @andreab1997 At the moment is using the whole of validphys since it uses the reader. It could only use the data through NNPDF/nnpdf#1965 but since at the moment it is optional I think it is ok. I have not updated the dependencies because at the moment they are quire restrictive and don't want to go around updating eko/banana/python/etc. I've tried putting 3.9-3.13 and that broke banana. I've updated only pineappl (which should be updated also in master). |
3.13 is definitely unsupported :P |
|
It's <3.13 |
banana is 3.12 ready: https://github.com/N3PDF/banana/blob/fc46349d8c0abd778afe0d2f949be2ec3f3a6bda/pyproject.toml#L28 (as we needed it for eko) - edit: blub you're trying to fix pineko 🙈 |
Ok I will review this ASAP |
giacomomagni
left a comment
There was a problem hiding this comment.
@scarlehoff Right now the yamldb is used also in the kfactor module, can you change that one as well ?
|
Do you want me to do it before #161 ? The changes needed for this are very minimal so it might be better to wait? |
|
on second thoughts, should this even touch the kfactors part? We should not need kfactors going forward, specially for the new data? |
I think whoever is ready to be merged first can go ... we need to sort out the dependency problem here first: at the moment Github is just complaining that the lock file is outdated
in the long run maybe yes, but surely we still need support for a while (e.g. for EW) |
Not from pineko |
I believe there are two point of views:
|
|
Why is pylint being applied to the benchmark as well? |
87795b3 to
db98a53
Compare
db98a53 to
1ea50fa
Compare
|
Ok, this is done as far as I'm concerned. Hopefully it even works. I've been using it for the perturbative charm theories. The kfactor at the moment (current I can modify if you want but that is just going to create unnecessary conflicts with #161. |
mh? it is not: Line 71 in 812893e problem is pylint needs to be update to be compatible with 3.12 - see also NNPDF/eko#349 |
andreab1997
left a comment
There was a problem hiding this comment.
Other than the trivial comment about the function location, this is ok for me
Not the benchmark folder but rather in the benchmark task. |
I see - boh' the code should be just always checked and it doesn't hurt (and in case it does we know immediately that something is fishy - even if it is just the pylint version) |
|
But repeating the same check in several different workflows just reduces the amount of information you get out of the failures. |
Actually, I wanted to have a separate workflow called |
|
Before merging this I would like to prepare a test so please don't yet. edit: you cannot merge it if I forget to add the files. Genius! |
Why? This is not using the theories from NNPDF. |
Sure, but it doesn't use the yamldb as well, it only looks at theory cards. |
Update fonll docstr and json loading
With this
pinekowill usennpdfwhenever thennpdf=Truekey is set in the[general]part of the config.Since when using
nnpdf, theyamldbis not needed, I've dropped it from required keys.At the moment this is not the default. I think it should become default because the NNPDF no longer looks at the yamldb files, the data is the only source of truth, so the fktables should have the same names. But this is something that can always be done manually afterwards.