Add ATLAS_DY2D_8TEV dataset

[cschwan]

This branch add the ATLAS_DY2D_8TEV dataset from arXiv:1606.01736, with data at http://hepdata.cedar.ac.uk/h8test/view/ins1467454.

Issues:

• cuts are set for the muon dataset, if electrons are selected at least one cut is missing (rapidity difference)
• static scale choice set the Z-boson mass, unclear what NNPDF uses fixed with a dynamic scale in commit 7c5f09b
• unclear what the rapidity cut is - is it 2.4 as written in section 2.4 or 2.5 in section 6?

[enocera]

@cschwan Let me try to address your issues.

• In the NNPDF code we actually implemented the combined (electron-muon) data set. If electrons are more precise than muons, then we shall perhaps prefer electrons over muons.
• For each bin, we use the central value of the invariant mass of the dilepton pair in that bin.
• I think that the cut in the runcard should be 2.5, as described in Sect. 6. My understanding is that muons are measured within |eta|<2.4 and electrons within |eta|<2.47, but then cross sections are extrapolated in both cases to |eta|<2.5, see the penultimate paragraph of Sect.6.

[cschwan]

@enocera : Can you please verify that the dynamic scale chosen in commit 7c5f09b is the right one? Using it I'm seeing differences in percent in the comparison against the APPLgrid results. Is the scale instead maybe chosen on a event-by-event basis as the invariant mass of the lepton pair?

[enocera]

@cschwan I understand that the dynamic scale you're using corresponds to the invariant mass of the lepton pair, whose value is taken as the centre of the corresponding bin, for each of the five bins. Is it correct? I'd say that this choice is fine and consistent with what we do in other cases. I'm therefore inclined to believe that the applgrids you are comparing to were produced with this same scale choice. However, this remains a conjecture: as far as I know, the applgrids were produced (not by me) with madgraph+amcfast in the context of the luxqed NNDPF paper 1712.07053, where they do not specify which scale was used. I suspect that the applgrids were brought from an earlier study by ATLAS 1701.08553. Reading through this last paper (see page 4) it seems to me that the dynamic scale, as defined by you, is used. They also say that using a fixed scale equal to the Z boson mass results in a difference of the order of few percent (it might explain the discrepancy you're observing?). I shall also note that I see (in the applgrids repository) applgrids for the PI contribution; it's not clear to me whether these are included in the default applgrids (I'd naively say NO), and therefore if the corresponding contribution has to be subtracted (I'd naively say NO) in order to benchmark against your pure QCD computation. Maybe @scarrazza, who was an author of the luxQED NNPDF paper, knows better than me what's going on?

[cschwan]

Oh I see, it might be the fact that I've used a non-zero photon PDF. This will, of course, make a difference because these contributions are zero in the APPLgrid.

[cschwan]

@enocera : Thanks, the photon PDF was the explanation (how often do I have to repeat the same mistake?). I now get a reasonable agreement with the NLO QCD (using NNPDF31_nlo_as_0118, negative numbers mean that the APPLgrid result is larger, differences in per mille):

 1.01515495   0.66526356   1.16957137   1.65487433   4.31488196
-0.93091149   0.68441077   2.24603444   4.83322169   2.84621436
-1.24221499  -0.59920943   0.21620004   2.14776787  -1.13921268
 0.01452671   2.68154442   0.75028475  -3.81056593   0.62294888
 3.04915255   0.05089465  -1.52687696   3.75324522  -1.10355480
-1.36169481  -0.01230944  -0.17785233   1.61404577   2.16236244
-0.41505653  -7.14095480   4.66268344  -2.66809778   3.94664956
-0.13833064  -4.88984375  -1.37704503  -2.69275471  -2.05285167
-3.63685329   3.42835057  -8.51731831 -11.80759183 -15.26641893
-22.79166651 -13.28142224 -32.58631293

The last bins differ by a few percent, but this is within the MC uncertainty. In this case I assume I can simply increase the precision.

[enocera]

@cschwan Very good, thanks!

[cschwan]

Here a second comparison, same parameters as before:

 0.719996815   0.854955238   0.946797651   1.614179465   3.616848238
-0.929605436   0.343393322   2.233921871   4.284128306   2.040145166
-0.861742004  -5.362124182   1.794704964   2.023896680  -0.717251392
 1.156632947   2.583249414   1.051919313  -4.232143476   0.577496309
 3.999747981   0.573181374   0.218163404   7.382069050  -1.078471044
-2.426022756  -0.077383021   0.006487555   0.271122474   0.554828288
 0.461820810  -7.584403527   3.467869840  -4.281832217   4.327482990
 4.335663663  -2.448113679  -1.559316145  -2.251406365  -0.900099909
-4.349390895  -1.339079103 -10.660244391 -10.836678697 -16.236067275
-16.132976802 -28.360801142 -26.409238182

This still doesn't look perfect for the last bins. The MC uncertainties in per cent for the last six bins are

0.06194273 0.05916693 0.06783980 0.18410423 0.39255171 0.77802917

This could mean that the MC uncertainties of the APPLgrid were just a bit too large.