-
Notifications
You must be signed in to change notification settings - Fork 3
Expose grid.evolve
to the C-API
#344
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
Conversation
Hi @Radonirinaunimi, yes, it does make sense. |
Hi @vbertone, apologies for the late reply, I wanted to sort out the interface first before providing you with how the order of the flattening should look like. However, I had not anticipated how difficult the interface would be, and therefore this is not done yet. It might still takes some time. |
Hi @Radonirinaunimi, no problem at all. Take your time. |
Ok, this is not completely done (needs some clean up, fix some memory leak in the example, etc.) but I think we can start to test and experiment it. So there is a primary example in evolve-grid.cpp. The operators should be flattened following the std::size_t index = 0;
for a { for i { for b {for l { eko[index++] = ... } } } } The pineappl/examples/cpp/evolve-grid.cpp Lines 62 to 71 in 43b1619
Please let me know if something is wrong/doesn't make sense. |
This is now doing what we intended to do. @vbertone please test it and let me know. You can download the Grid for the test via: wget --no-verbose --no-clobber https://data.nnpdf.science/pineappl/test-data/LHCB_WP_7TEV_opt.pineappl.lz4 @cschwan This is not super-clean yet and would appreciate if you can have a quick look (your feedback is always quite helpful). |
Hi @Radonirinaunimi, thanks a lot, I will test it as soon as possible! |
Hi @Radonirinaunimi, I just ran the code and it does work fine. Also, starting from here I should be able to follow the steps to eventually interface it to the evolution operator computed with APFEL++. I just have one question. Here is the output I get:
So differences between grid and FK-table predictions are on the verge of 1%. Since the grid that is being used is (I guess) a realistic one and that the evolution is essentially the unity, this seems a purely numerical effect related, I suppose, to interpolation. The question is: is this accuracy satisfactory? And can in principle be improved? Thank you. |
Hey @vbertone and @felixhekhorn, there was a bug in the masking of the orders of the example (fixed in b2bf81b). Now the agreement is:
|
Thank you, @Radonirinaunimi, this looks much better! |
Hi @Radonirinaunimi, I'm having some difficulties in understanding the behaviour of the code. Specifically, I would like to change the output PIDs because evolution can possibly generate channels that are not originally present. To this purpose, I made the following basic changes to the code
The purpose is to allow for all possible channels. However, I must be doing something wrong because when I run the code I get this error that I cannot interpret:
I also tried to play around with the order of variables here and there, but still get the same error (except that sometimes the two tensor shapes in the error message are swapped). Any idea of what I'm doing wrong? Thank you. |
Hi @vbertone, the error is because a mismatched shape between the EKO |
Yes, the header of this function is almost ( |
Ah, you're right (I wrote it on the fly and did). So I guess the solution is to return the |
I'm not sure how long it'll take to implement the changes, but if you can live without these changes in v1.0, @Radonirinaunimi, you can release v1.0 without this PR, which can just as easily add in v1.1. The important bit for v1.0 was #343, which has been merged. |
Hi @cschwan, I think these are sensible modifications so I will try to finish them in the next days before finally making the |
…peratorCallback`
So @vbertone, we are finally going to merge this. The function signatures have changed a bit but they are now final. Please let me know in case you need my input in updating the PineAPFEL interface. |
Hi @Radonirinaunimi, thanks for letting me know. |
Hi @Radonirinaunimi, I've just downloaded and installed the latest master of
Any input from your side is welcome. Thank you! |
Using
grid.evolve
to evolve grid with APFEL++ evolutionIn addition to performing the evolution on the fly and outputting theory predictions, APFEL++ also wants the possibility to dump the evolved grids on disk for future usage (aka FK tables). This effectively implies
grid.evolve
to be exposed at the C interface.@vbertone, the idea is then for you to provide an operator which is a rank-4 tensor. To be more illustrative, let's consider a simple DIS case. The convolution, for a fixed$Q^2$ , writes as:
where:
These form the dimensions of an EKO, ie$x$ -grid coordinates of the grid and FK table do not have to be same, and they do not have to be the same as what is actually inside the grid $-$ same is true for PID bases.
EKO[a][i][b][l]
. Notice that theThe C++ function that consumes the operator from APFEL++ would therefore tentatively look as follows:! Deprecated, see evolve-grid.cpp.and this is the function that'll dump the evolved grid. I think this is the best way to do it as opposed to what we discussed during the meeting.
So the summarize, what APFEL++ needs to provide (for a given value of$Q^2$ ), is a rank-4 tensor representing the EKO. In addition, we need the $x$ and PID values (can be in any basis) from which the EKO was computed $-$ this way we don't rely on much information from the grids to construct the EKOs.
Does this make sense?
Extra-changes included in this PR (not fully related):
get-subgrids.cpp
examplesTODO:
LHCB_WP_7TEV_opt.pineappl.lz4
grid for the test which currently is available at:Infer the order masking in the example from the GridEKO_LHCB_WP_7TEV.txt
which contains the flattened evolution operators