cschwan commented 3 years ago

DIS grids need only a single PDF convolution, so that we have to rethink caching, reweighting, and storage a bit.

codecov[bot] commented 3 years ago

Codecov Report

Merging #50 (ee1a47c) into master (1792470) will increase coverage by 0.18%. The diff coverage is 87.50%.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
+ Coverage   91.64%   91.83%   +0.18%     
==========================================
  Files           9        9              
  Lines         934     1151     +217     
==========================================
+ Hits          856     1057     +201     
- Misses         78       94      +16

Impacted Files	Coverage Δ
pineappl/tests/drell_yan_lo.rs	`100.00% <ø> (ø)`
pineappl/src/grid.rs	`82.07% <69.23%> (+2.86%)`	:arrow_up:
pineappl/src/lagrange_subgrid.rs	`91.96% <89.50%> (-2.14%)`	:arrow_down:
pineappl/src/ntuple_subgrid.rs	`96.15% <100.00%> (+0.32%)`	:arrow_up:
pineappl/src/subgrid.rs	`100.00% <100.00%> (ø)`

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 1792470...ee1a47c. Read the comment docs.

alecandido commented 3 years ago

interpolation polynomial degree

We always try (I'd like to say struggle, but unfortunately it's not true...) to use the proper and explicit names: in this case that number it's really the degree of the polynomials used, so the maximum power.

linear interpolation: degree 1, 2 points per polynomial
quadratic interpolation: degree 2, 3 points per polynomial

I don't know exactly what do you mean by no interpolation, but if you consider a piecewise constant it should be 0 (I still have to check it's an available choice, I'll do easier with Felix).

hadronic `x` vs partonic `z`

I'm sorry this is really an example where we are naming inconsistently: we realized at some point we are making a mess with this names, also because there would be a third variable around (that it is actually x/z and we usually call xi), since the x is the hadronic one, but also coefficients functions do not live in the same variables of the PDF.

Unfortunately the interpolation_xgrid it's really a zgrid (without taking care of the third one, otherwise it would properly be a xigrid), since we are never interpolating in hadronic variables in yadism (neither x nor Q2).

Maybe we'll consider renaming in any case, just to make it cleaner for ourselves, but physics papers are inconsistent in the first place (also because of the PDF/structure function legacy ambiguity, I guess).

interpolation edges

If I understood the problem the answer should be in this picture:

I.e.: if your point fall in an area next to an edge (or sufficiently close to "interact")

the polynomial used it's the one of the block in which the area it's most central

e.g. for A0 it's B0, because, even if it's not central at all, the other blocks are worse, and you try to preserve the order of the interpolation.

docs

In general Felix it's maintaining a good documentation on eko for this kind of things, and even if it's not intuitive yadism it's exploiting the interpolation of eko, in order to maintain a single copy of the code.

The docs of yadism instead it's crap...

cschwan commented 3 years ago

interpolation polynomial degree

OK, thanks, in that case we have the same understanding of the parameter, although you use an interpolation that's one order higher than PineAPPL's default - that's not a problem, however.

interpolation edges

I see, in that case we - again - do exactly the same!

cschwan commented 3 years ago

@AleCandido, @felixhekhorn : what's the meaning of interpolation_is_log?

felixhekhorn commented 3 years ago

@AleCandido, @felixhekhorn : what's the meaning of interpolation_is_log?

whether to use logarithmic interpolation or not, i.e. make polynomials of x or log(x) - this will almost always be true (but since it costed nothing to implement it is there ...)

Unfortunately the interpolation_xgrid it's really a zgrid

well, only in yadism - but since this is eko technology, the name should be really _xgrid - as we interpolate f( x ,Q^2) there and immediately go to N-space so there convolutions never appear and thus there is no need to distinguish between x, z, and xi

felixhekhorn commented 3 years ago

I don't know exactly what do you mean by no interpolation, but if you consider a piecewise constant it should be 0 (I still have to check it's an available choice, I'll do easier with Felix).

yes, indeed, at the moment we require at least linear interpolation; which is a choice, of course, but I would expect continuity to improve integrations a lot ...

cschwan commented 3 years ago

I see. I started writing an importer, and I discovered a few points where we have to decide the next steps:

PineAPPL's Lagrange interpolation polynomials are always polynomials of x, not of log(x). As far as I understand this means interpolation_is_log: false?
So far I also can't import a custom-spaced grid

I will import all the missing features in the future, of course, but I wonder whether you could (easily) produce another output, with interpolation_is_log: false and 50 points in the PDF z argument, at the following coordinates:

1
0.9309440808717544
0.8627839323906108
0.7956242522922756
0.7295868442414312
0.6648139482473823
0.601472197967335
0.5397572337880445
0.4798989029610255
0.4221667753589648
0.3668753186482242
0.31438740076927585
0.2651137041582823
0.2195041265003886
0.17802566042569432
0.14112080644440345
0.10914375746330703
0.08228122126204893
0.060480028754447364
0.04341491741702269
0.030521584007828916
0.02108918668378717
0.014375068581090129
0.009699159574043398
0.006496206194633799
0.004328500638820811
0.0028738675812817515
0.0019034634022867384
0.0012586797144272762
0.0008314068836488144
0.0005487795323670796
0.00036205449638139736
0.00023878782918561914
0.00015745605600841445
0.00010381172986576898
0.00006843744918967896
0.00004511438394964044
0.0000297384953722449
0.000019602505002391748
0.00001292101569074731
0.000008516806677573355
0.000005613757716930151
0.0000037002272069854957
0.000002438943292891682
0.000001607585498470808
0.0000010596094959101024
0.0000006984208530700364
0.00000046035014748963906
0.0000003034304765867952
0.00000019999999999999954

The accuracy will be bad without the reweighting function, of course, but for the time being we just want to produce the same numbers. Let me know if that is too complicated/time-consuming.

cschwan commented 3 years ago

@AleCandido , @felixhekhorn : How are the individual orders stored in the yaml file, that is how do I extract the leading order, the next-to-leading order?

felixhekhorn commented 3 years ago

but I wonder whether you could (easily) produce another output, with interpolation_is_log: false and 50 points in the PDF z argument, at the following coordinates:

yes, we can (although I'm not sure I will manage before lunch break ... ;-) )

How are the individual orders stored in the yaml file, that is how do I extract the leading order, the next-to-leading order?

the example is at LO only - we haven't implemented the splitting by alpha_s yet ...

alecandido commented 3 years ago

I'm attaching the requested numbers pineappl-sample.zip.

Actually we have a really bad agreement with APFEL, and it seems like it's completely a grid's fault. Following the numbers with an usual grid:

comparison on the usual interpolation zgrid


--------------------------------F2total--------------------------------

           x           Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.000317    90.000000  1.639572  1.639572           0.0   -0.000004
1   0.001007    90.000000  1.182349  1.182349           0.0   -0.000004
2   0.003195    90.000000  0.846563  0.846563           0.0   -0.000004
3   0.010138    90.000000  0.623498  0.623498           0.0   -0.000004
4   0.032169    90.000000  0.483802  0.483802           0.0   -0.000004
5   0.102077    90.000000  0.370392  0.370392           0.0   -0.000004
6   0.304545    90.000000  0.225637  0.225637           0.0   -0.000003
7   0.536364    90.000000  0.072848  0.072848           0.0   -0.000003
8   0.768182    90.000000  0.007164  0.007164           0.0   -0.000003
9   1.000000    90.000000  0.000000  0.000000           0.0         NaN
10  0.001000     4.000000  0.650321  0.650314           0.0   -0.001137
11  0.001000     5.348935  0.692437  0.692429           0.0   -0.001163
12  0.001000     7.152778  0.737409  0.737400           0.0   -0.001197
13  0.001000     9.564937  0.784643  0.784633           0.0   -0.001241
14  0.001000    12.790557  0.833650  0.833639           0.0   -0.001294
15  0.001000    17.103966  0.884039  0.884027           0.0   -0.001352
16  0.001000    22.872003  0.935463  0.935449           0.0   -0.001413
17  0.001000    30.585218  0.987656  0.987642           0.0   -0.001475
18  0.001000    40.899589  1.040354  1.040338           0.0   -0.001539
19  0.001000    54.692316  1.093394  1.093377           0.0   -0.001607
20  0.001000    73.136417  1.146642  1.146623           0.0   -0.001677
21  0.001000    97.800494  1.199934  1.199913           0.0   -0.001739
22  0.001000   130.782133  1.253168  1.253146           0.0   -0.001803
23  0.001000   174.886299  1.306275  1.306251           0.0   -0.001870
24  0.001000   233.863883  1.359143  1.359117           0.0   -0.001938
25  0.001000   312.730705  1.411711  1.411683           0.0   -0.002004
26  0.001000   418.194092  1.463956  1.463926           0.0   -0.002067
27  0.001000   559.223306  1.515778  1.515746           0.0   -0.002129
28  0.001000   747.812346  1.567174  1.567139           0.0   -0.002190
29  0.001000  1000.000000  1.618106  1.618070           0.0   -0.002251
-----------------------------------------------------------------------

-----------------------------FLtotal-----------------------------

           x           Q2  APFEL  yadism  yadism_error  rel_err[%]
0   0.000317    90.000000    0.0     0.0           0.0         NaN
1   0.001007    90.000000    0.0     0.0           0.0         NaN
2   0.003195    90.000000    0.0     0.0           0.0         NaN
3   0.010138    90.000000    0.0     0.0           0.0         NaN
4   0.032169    90.000000    0.0     0.0           0.0         NaN
5   0.102077    90.000000    0.0     0.0           0.0         NaN
6   0.304545    90.000000    0.0     0.0           0.0         NaN
7   0.536364    90.000000    0.0     0.0           0.0         NaN
8   0.768182    90.000000    0.0     0.0           0.0         NaN
9   1.000000    90.000000    0.0     0.0           0.0         NaN
10  0.001000     4.000000    0.0     0.0           0.0         NaN
11  0.001000     5.348935    0.0     0.0           0.0         NaN
12  0.001000     7.152778    0.0     0.0           0.0         NaN
13  0.001000     9.564937    0.0     0.0           0.0         NaN
14  0.001000    12.790557    0.0     0.0           0.0         NaN
15  0.001000    17.103966    0.0     0.0           0.0         NaN
16  0.001000    22.872003    0.0     0.0           0.0         NaN
17  0.001000    30.585218    0.0     0.0           0.0         NaN
18  0.001000    40.899589    0.0     0.0           0.0         NaN
19  0.001000    54.692316    0.0     0.0           0.0         NaN
20  0.001000    73.136417    0.0     0.0           0.0         NaN
21  0.001000    97.800494    0.0     0.0           0.0         NaN
22  0.001000   130.782133    0.0     0.0           0.0         NaN
23  0.001000   174.886299    0.0     0.0           0.0         NaN
24  0.001000   233.863883    0.0     0.0           0.0         NaN
25  0.001000   312.730705    0.0     0.0           0.0         NaN
26  0.001000   418.194092    0.0     0.0           0.0         NaN
27  0.001000   559.223306    0.0     0.0           0.0         NaN
28  0.001000   747.812346    0.0     0.0           0.0         NaN
29  0.001000  1000.000000    0.0     0.0           0.0         NaN
------------------------------------------------------------------

Also it's completely our fault, instead APFEL it's already stable also with the grid you provided.

felixhekhorn commented 3 years ago

Also it's completely our fault, instead APFEL it's already stable also with the grid you provided.

but APFEL can not do is_log = False, can it? and I would consider this a big problem (esp. at small x) ...

cschwan commented 3 years ago

The last commit adds a preliminary importer written in Rust, which processes the yaml file. It's only a first idea, of course, but one that'll allow me to make quick changes where necessary. In the future we should port this to the Python API (which needs to updated) and probably integrated with YADISM.

cschwan commented 3 years ago

By the way, I noticed that xiF = 0.5, while previously it was 1.0. Does that make a difference for the APFEL/YADISM comparison?

alecandido commented 3 years ago

~~Here~~ the numbers for the same PDFset as before, with anything set to 0 but up quark.

Sorry, too fast, I used the wrong settings. You can find the correct one here.

cschwan commented 3 years ago

Just to make sure I've understood it: for these numbers, for the first (x, Q2) combination out of 30, the PDF is evaluated at 90.0 / 4 = 22.5 GeV^2 ?

cschwan commented 3 years ago

Hm, I can't reproduce these numbers. Could you please tell me if your convolution for the first bin (x = 0.000317313166918093 and Q2 = 90.0) performs the following calculation (probably from bottom to top):

|          x             |  grid                  | xfx/x              |
|------------------------|------------------------|--------------------|
| 0.0008314068836488144  | 6.6200561366736869e-07 | 992.44664199521708 |
| 0.0005487795323670796  | 1.2168313891842761e-05 | 1638.4356093840456 |
| 0.00036205449638139736 | 0.0001823318629726802  | 2705.2851003621563 |
| 0.00023878782918561914 | 0.00012467506999862632 | 4465.6361284334389 |
| 0.00015745605600841445 | 2.5701731164308698e-05 | 7369.3434654786288 |

My value is the sum of over the products of grid with xfx / x values, which is 0.8413282909766213.

felixhekhorn commented 3 years ago

unfortunately, we were a little bit inconsistent with our provided data files, so we regenerated everything in one (reproducible) script and wrapped everything for you here
however, looking at the data from before we also realized that maybe you're neglecting signs on the grid, e.g. 1.2168313891842761e-05 before was negative ... (or do you just do not print it?)

Just to make sure I've understood it: for these numbers, for the first (x, Q2) combination out of 30, the PDF is evaluated at 90.0 / 4 = 22.5 GeV^2 ?

this was indeed part of the inconsistencies, so we rerun with xiF = 1

cschwan commented 3 years ago

* unfortunately, we were a little bit inconsistent with our provided data files, so we regenerated everything in one (reproducible) [script](https://github.com/N3PDF/yadism/blob/feature/reorder-weights/benchmarks/runners/pineappl.py) and wrapped everything for you [here](https://github.com/N3PDF/pineappl/files/5621820/pineappl.zip)

* however, looking at the data from before we also realized that maybe you're neglecting signs on the grid, e.g. `1.2168313891842761e-05` before was negative ... (or do you just do not print it?)

Yes, unfortunately I omitted the signs; they were killed when I drew the ASCII table. The calculation isn't affected by this, however.

cschwan commented 3 years ago

OK, I can now reproduce your up-quark-only numbers perfectly (all digits).

cschwan commented 3 years ago

Where can I get the result for all flavours? The following are mine:

0 2.3452168120488217
1 1.6402033670238398
2 1.1307150109637594
3 0.7810037379397343
4 0.5540483217587314
5 0.39543367275844377
6 0.23020617651348313
7 0.07323179311056445
8 0.007167428326700186
9 0
10 0.6403681591222482
11 0.7841994710639457
12 0.8595438246380247
13 0.9383733916374735
14 1.019907629976648
15 1.1035237300164635
16 1.1889069501523761
17 1.2846395609710046
18 1.381212375598325
19 1.4780730285313486
20 1.5751481542257713
21 1.6721643282552434
22 1.7689426102155583
23 1.8653650425323256
24 1.9612405473180687
25 2.0564733716704633
26 2.15102801470353
27 2.2447310385821013
28 2.3375806407818738
29 2.429517892518539

Do I have to multiply CKM factors to the PDFs?

felixhekhorn commented 3 years ago

you meaning using the full pdf set with all flavors for all kinematic points? if so, mmm, we're getting something different ... pineappl_sample_CT14llo_NF6_0000.zip

Do I have to multiply CKM factors to the PDFs?

no - all charges (and similar) we're already applied (since this is a non-trivial business ;-) )

cschwan commented 3 years ago

you meaning using the full pdf set with all flavors for all kinematic points? if so, mmm, we're getting something different ... pineappl_sample_CT14llo_NF6_0000.zip

Do I have to multiply CKM factors to the PDFs?

no - all charges (and similar) we're already applied (since this is a non-trivial business ;-) )

Strange; how long does take to run the numbers? If it doesn't take too long we could meet and include the flavours one-by-one and debug it together.

alecandido commented 3 years ago

Fine, for us generating the number is just taking the time of writing "{flavor}only" here and there and ~1.4s to run, so nothing.

If it's working for you we can meet at 2PM and debug together.

cschwan commented 3 years ago

OK, let's do that!

cschwan commented 3 years ago

The example program now correctly writes a PineAPPL grid and pineappl, the CLI program, can successfully produce predictions. Now I think it's time you double-check the results!

NNPDF / pineappl

Add support for a DIS grid #50

Codecov Report

interpolation polynomial degree

hadronic `x` vs partonic `z`

interpolation edges

docs

interpolation polynomial degree

interpolation edges

NNPDF / pineappl

Add support for a DIS grid #50

Codecov Report

interpolation polynomial degree

hadronic x vs partonic z

interpolation edges

docs

interpolation polynomial degree

interpolation edges

hadronic `x` vs partonic `z`