-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize FkTable
representation
#79
Comments
That's a good idea. However, it only works when the 1) charm PDF is equal to the anti-charm PDF and if, at the same time, 2) bottom- and top-quark PDFs are zero at the FK table scale. Since this isn't the case in general, but is the case for NNPDF, the place where we can do this is in In practice I'd give |
@felixhekhorn had the same worry. I'd say for now we can accept that to be true
But this is always true (or always false) for a given fktable, right? Personally I was thinking of *of course, I'm even happier if their size is reduced also in disk but that's a second order problem for me |
But as you said this is a NNPDF thing so let's do as @scarlehoff and I said in person: let's change the |
I agree on not to add any further complication to However, instead of providing methods for a different representation, I would add a method to get a new |
at some point definetly yes, however let's focus for the moment on the things we need to reach our deadline 🙃 |
I would say that the idea of returning a new collapsed object serves well any possible usage:
|
FkTable
representation
That's a good idea! We could call it |
I agree, at the end of the day an |
Mmm but this clashes with our idea of an FKTable beeing immutable ... |
Not really, because it returns another |
but will this work if the thing is not clonable? (and we want this) |
That's a good question... |
@alecandido @felixhekhorn Important question: are the grids (opposed to the grids convoluted with PDFs) for sigma, T24, T35, and for V, V15, V24, V35 the same? In that case we can easily implement this optimization at the level of redefining the luminosity functions. |
No (if I understand correctly) because some processes, e.g. CC DIS or CC DY, can resolve difference between b and bbar, e.g., and hence V24 and T24 are unique |
@cschwan is this available? i..e, can I do .optimize() to get
? Or maybe this should be done by pineko (since it depends on the final scale)? @felixhekhorn |
@scarlehoff The short answer is no. How important is that for the fit in terms of a timescale? I'm a bit hesitant to implement the optimization because I'm still wondering what the proper way to do it would be. Isn't this technically a different basis? In any case I'd like make the assumptions explicit somewhere so that the user can't use a PDFs where these assumptions are not fulfilled. |
When we do the fit with all the tables the memory is going to grow quite a bit and thus the fits will take longer. It's not a disaster but it's a big QoL feature.'
Yes and no. It's just an optimization over the evolution basis at a given scale.
One possibility is that this is done at loading time, so that one can ask for the fktable table or the optimized_fktable where some of the values are summed (for instance T24 and 35 get absorbed into singlet) Saving them in an already optimized format makes it easier in the storage but I don't care that much about that part. |
I see, that's why I've added this to the v0.5.0 milestone. Would the interface to the fit understand if I'd remove T24, T35, V15, V24 and V35 from the list of luminosities or should I keep them in there (their contribution would be zero)? @felixhekhorn @alecandido I'd suggest to add one parameter to |
Since this is an optimization feature I guess all 0s should be removed for maximum optimization. |
In any case, we don't want this to be a breaking change: we want the fit to work without, but it would be quite bad if it's not going to still work with the 0s. Thus, I propose to release v0.5.0, and start a v0.5.1 milestone |
Since |
Commit cf02e33 should implement all interface-visible changes to do exactly what @scarlehoff proposed. As promised there's one new method and let me know if I can improve it. It should enable a general version of the optimization that @scarlehoff proposed in the first comment, if we want to fit bottom = anti-bottom, for instance. The optimization should work for FK tables in the flavour and evolution-basis. What we need next is 1) the corresponding method in the Python interface and 2) probably a slightly modified theory that specifies the assumption and that calls this method in Pineko/fktable. @alecandido @felixhekhorn could you please have a look at this? What's still missing is the actual optimization, for the time being only the luminosity function is rewritten and therefore one gets repeated entries. I'm working on that now. |
I'll update immediately Python interface, I guess there are only two things to bind:
It should not be hard. |
In 834a041 I added the bindings for the method. I had to make the |
At this point it would have been worth a dedicated PR ;-) |
In c63b0ea it becomes actually possible to generate Since this mapping is encoded twice: I would suggest to split it in an |
@alecandido I agree, I'll implement the trait |
Ok. At the moment, it is what it is, if you wish to remove it you can do it, but since it's not part of a release I believe we can keep it, and use creation from Python just to experiment. The moment you have a better candidate, I'll make sure to update. |
Implemented in commit 4427e9e. |
Commit 19aa0a5 should implement everything we need, and adds the option |
Well done :D Is there anything left that is needed (but testing) @scarlehoff? |
To first approximation only testing. |
First tests look very promising:
|
Finally it seems to do what it promises:
doesn't show evolution IDs higher than Applying |
As far as PineAPPL is concerned this Issue can be closed, if you agree. Don't forget to call |
In order to use this in If you don't have anything more to add close in the future @cschwan, I would just release |
I have one question, the |
That's correct, @scarlehoff! |
For instance, at the initial scale we have that
sigma = T24 = T35
V = v15 = v24 = v35
One thing that the NNPDF fktables do is to say "ok, since these are equal I'll just sum everything in, say, V, and empty the other rows" so one gets "V+V15+V24+V35" but the luminosity function is just V.
The text was updated successfully, but these errors were encountered: