E906

[scarlehoff]

Thanks to @enocera the problems with E886 have been fixed and only the factor of 54.35 is left to be understood.

For E906 we are almost there:

          vp          pineappl         ratio
0     1.191242  1.201472  0.991485
1     1.199608  1.177030  1.019182
2     1.186598  1.136463  1.044114
3     1.149721  1.102780  1.042566
4     1.072231  1.060470  1.011091
5     1.023621  1.067877  0.958557

As you can see, the ratio is almost 1, which means that what we are doing is probably not completely stupid. The interesting thing is that the individual bins are quite wrong and are worse for the latest bins. For instance, for DYE906R_D we find for the first bin:

0     0.037554  0.000000       inf
1     0.037554  0.000000       inf
2     0.037554  0.000000       inf
3     0.037554  0.000000       inf
4     0.349985  0.348493  1.004283
5     0.203273  0.204341  0.994769

For the second bin:

data                              
0     0.037576  0.000000       inf
1     0.037576  0.000000       inf
2     0.709360  0.637249  1.113160
3     0.518561  0.467693  1.108763
4     0.281803  0.268934  1.047850
5     0.142239  0.142816  0.995960

it's already a bit worse but not terrible!

And for the last one:

             0         0         0
data                              
0     0.075938  0.451249  0.168284
1     0.058310  0.250169  0.233081
2     0.041711  0.124785  0.334265
3     0.027890  0.061750  0.451661
4     0.018087  0.035690  0.506775
5     0.011037  0.020990  0.525853

completely off! Note that this is before applying any acceptance factors.

My next step will be checking with https://arxiv.org/pdf/2103.04024.pdf that the values of the rapidity and mass that I am using are correct for all bins. I believe there might be some spurious factor left (because the fact is the ratio is close to the actual result while the separate bins are mostly wrong) but I wanted to give you guys an update since I won't be able to do anything else until Friiday/Monday.

[scarlehoff]

So, there was a problem with the rapidities in the vrap runcard which did not correspond to those in buildmaster. Upon correcting that I get the usual perfect agreement

And the last of the FTDY is done: DYE906R.

             0         0         0
data                              
0     1.191242  1.193548  0.998068
1     1.199608  1.208463  0.992673
2     1.186598  1.190897  0.996390
3     1.149721  1.155509  0.994990
4     1.072231  1.075147  0.997288
5     1.023621  1.028386  0.995367

The ones for the first few bins were also wrong.

There are still two subins that still not match between the tables computed with APFEL and the ones computed with vrap but they have a very small ACC cfactor and interestingly enough the mistakes cancel on the ratio. I believe the values in vrap are more correct than the ones on APFEL because they clearly look like outliers.

I'll clean a bit this and will add this to the external repositories before using it as well for the positivity observables. I need to speak with @cschwan to see whether there might be a way of bypassing the need for 20 different fktables for a single observable.

[cschwan]

When you say 20 different FK tables I suppose you mean these:

https://github.com/NNPDF/apfelcomb/blob/master/db/apfelcomb.dat#L609-L628

I don't see a reason why we can't put everything into a single FK table, I wonder why this was done in the past. Do the legacy FK tables support 2D bins (that might be the reason)?

[enocera]

@cschwan The reason is that the way in which these FK tables are combined is to take each of them, multiply each of them by an acceptance factor, and then construct the observable as the ratio between the sum of tables 1-10 and the sum of the tables 11-20 (where each term in the sums is multiplied by a different acceptance factor).

[cschwan]

@enocera Thanks for the explanation. In that case we probably can get away with producing just two tables, one for protons, one for deuterons, and we will have to implement some functionality to rescale PineAPPL grids/FK tables with bin-dependent factors, opposed to rescale entire FK tables with a single factor.

[cschwan]

@enocera Are the acceptance factors the ones listed in 'Extended Data Tab. 3' on the last page of https://arxiv.org/abs/2103.04024?

[enocera]

@enocera Are the acceptance factors the ones listed in 'Extended Data Tab. 3' on the last page of https://arxiv.org/abs/2103.04024?

Yes, they are. They are currently implemented as ACC K-factors.

[scarlehoff]

I'll merge this. The only thing left is the positivities. Once I write the runcards for that I'll move this to externals.