NNPDF
Detect theory changes and redownload
I'm wondering whether it would be possible for validphys to detect when there has been a changed in the theory_XX in the server and force a redownload (without having to remove the folder manually)?
I guess it is fine if the information of the fact that has changed is stored locally (so that you only know it has changed if you have a newer version of the code).
Was literally thinking about this yesterday in fact. I thought maybe we could add a flag that force redownloads any server based resources e.g fits, pdfs, theories etc.
Was literally thinking about this yesterday in fact. I thought maybe we could add a flag that force redownloads any server based resources e.g fits, pdfs, theories etc.
this flag seems useful at least for vp-get I'm not sure this flag would be super desirable when running a report, although maybe I'm wrong
Have it on and off on demand would be really good (so that it could maybe be on for n3fit but off for comparefits)
surely bad for n3fit because every replica would attempt to re download resources..
in fact I had replicas fail before because they were all fighting to download the t0 pdf first 😆
I guess that's a different problem to be solved... but I've had to rerun fits because I forgot there was some change in theroy_53 which makes me sad :__ I would've preferred a hard fail because of the download so I don't lose priority.
I think for n3fit you really want your original suggestions where it only downloads if it needs to, not simply a blunt force flag. Of course it would probably have to leverage the force flag that @siranipour is talking about to remove the previous theory..
The theory is probably the most unsatisfactory resource because it is subject to change. You don't really get this problem with pdfs and shouldn't with fits
Ah, yes, sorry. I was always thinking about a flag that looks whether it needs to redownload it!
At this point modifying fktables is evil and I am sad we don't have a good mechanism to do it. The problem is not only that you get new results wrong but also that it is impossible to know if old results use the old or new version of the result. Some general description of the problem and suggested solution is #224. Having a bunch of names for datasets as @enocera is doing for modifications in commondata is annoying to get right but at least takes care of the problem of knowing which version is what.
There was an old idea of having some kind of version control for fktables, as opposed to theories.That would be integrated with the defaults/lockfile system that we don't have and download new versions by default unless you specify the old ones.
The version control itself was a pain point: Something like github lsf has a few usability problems (e.g. for some reason I don't remember it was important that we delete old versions from time to time). Maybe this is one thing to look at https://github.com/iterative/dvc
