Add ATLASZPT8TEV{M,Y}DIST datasets

[cschwan]

This branch adds the ATLASZPT8TEV datasets from arXiv:1512.02192, with datasets available at https://www.hepdata.net/record/ins1408516. The runcards were copied from the CMS_Z_13TEV dataset and adjusted.

Issues:

• bin limits for the invariant mass distribution are unclear
• is the scale choice OK?

[cschwan]

In NNPDF there's a cut on the jet transverse momentum of 5 GeV,

https://github.com/NNPDF/external/blob/4e842676deada26d882e1932a5ffd53d4b87709e/MCFM-6.8/Bin/Input/ATLASZPT8TEVYDIST-BIN1.DAT#L56

which shouldn't be there. I expect this to make a large difference for YDIST in the low transverse momentum bins, but not for the bins that NNPDF uses in the fit. This was probably chosen to regularise the singularity at zero transverse momentum.

[enocera]

There might be a comment about this point in this paper
https://inspirehep.net/literature/1597432
or maybe Maria Ubiali knows.

[cschwan]

Here the comparison against the NLO QCD APPLgrids with NNPDF31_nlo_as_0118, showing differences in per mille, negative numbers correspond to a larger APPLgrid result:

MDIST:

 20.0917284  21.5415290  26.2062340  17.3151163  11.1303845   5.2054212
 15.7308334  -6.4114262   2.6246604   8.9586122   7.0997364   2.1658015
 11.2931941   2.7415876   0.5196463  -4.9652006 -13.1186615  -2.5735465
  1.6872026  -0.6324217  -5.4407937  -0.9900762   0.4802001   8.3537925
 24.3119193  15.5972107  24.6329875  14.2668021  22.4928512  16.3522389
  8.7413248  12.0952233  16.0033365   1.4860522   0.1234022   7.6067015
 -6.3578942  12.8108403   3.9752042  -5.0385603  -3.1768139  21.5422996
 -8.2566768  -1.2195133  -4.4875670   4.5444325 -11.4049064   5.2035294
 12.4783671 -12.9535187   4.7143987  -8.0494717  -7.2734901 -23.2834294
 -8.3266973   2.5993887 -31.7154030 -23.7096819   7.3633567   3.2900353
 36.8355769  29.4811241  15.9086792 -23.7210822 -15.7906773 -17.7225639
-10.4428678 -19.8095448 -25.5045082 -13.3545827 -29.8213427  -8.5893566
 -7.5328847 -19.7478887

YDIST:

 7.169003135   1.248497366   3.503888436   1.011740247   1.366984316
-0.193139436   0.674152573  -0.547562149   0.547117973   1.371058569
 2.191977302   4.009158934   2.869089777  -3.455216578   2.708985814
 0.731590859  -4.412077369  10.556427240   9.956362651   4.117578487
 1.997897344  -1.536559692   5.190889538  -3.797205447   1.738932257
 0.712492330   0.814067720   0.387285806   2.675488491  -2.702289438
 2.560480049   3.719105309  -1.287403561   0.851210759  -6.252243637
 7.704852873   1.136316873   3.281274785   4.584464201   4.545339935
 3.699039780   0.545781172   1.303308129   2.635048697   1.665926537
 0.319091089   0.419329470   1.337067162   0.122520717   0.340664625
 0.728507751   2.628499290   1.068792999   2.353636309  -2.140066930
 6.700991447   2.374082009  -4.672526409   3.879236610   5.949246510
-0.313908000   1.345507876  -7.004617713   1.609801434  -0.704540741
 0.493514177   1.882633570   1.647329461  -1.719669112   0.854317978
 1.282338289   3.745473790   0.022623427  -4.594755756   2.331386232
 0.135684605   3.581033873  -0.571369504   8.259364440   3.268014995
11.875914340   4.551066869   8.509526161   1.810071163   2.345218384
 1.581683249   0.827206065  -0.005215021   1.707707246   1.327160914
-0.970411940   3.175760218   1.033565427   1.319248275   1.968405654
-6.232289058  10.054352959   0.797089885   6.941251993   1.292377867
-1.180941531  12.584129669 -28.918417439  11.579077677   1.892749235
-1.951837167  -2.628693914  15.873726334  -7.719723073  -0.147326379
 0.855632681   3.101698939   2.899660638   1.414456849   4.213210096
 9.915603516 -11.550872956  -7.971245265   1.840297268  18.278068324

[cschwan]

@enocera I'd say for YDIST I've found agreement, while for MDIST is there's a difference - strange.

[cschwan]

@enocera Thanks to Marco and Maria we've very likely found the source of disagreement. Maria was able to find the MCFM runcards, in which the scale is set to

sqrt(M^2+pt34^2)

If you read the MCFM documentation (p. 20, table 11) it says that

M = mass of particle 3+4

which I (and also Alberto, who generated the grids) read as being the invariant mass of particles 3 and 4. However, Marco explicitly verified that it's actually the on-shell Z mass 😩.

[enocera]

@cschwan Thanks for investigating this issue!

[cschwan]

@enocera @marcozaro What I said above isn't the explanation (Alberto manually fixed the scale problem in MCFM), as the numbers are clearly worse:

-54.74549277  -43.91177354  -37.42344498  -33.26700644  -33.29730058
-23.72453503   -6.97588631  -13.16143729  -49.41736039  -42.07808704
-38.52510518  -33.75201230  -22.80085316  -27.00123121  -12.55446541
-10.30564425  -57.39789855  -44.39404995  -31.87181610  -35.01552228
-37.83104482  -22.39084977   -6.31067472   -3.82442679 -298.30357106
 -6.49002311   -1.12465488  -11.31968645   -0.31632004   -6.76332300
 -9.05064815   -3.67112821    7.64742733  -13.08892997 -642.99000832
  7.73391053   -6.83502094   14.85273371    3.14416801   -4.12750096
 -4.63815182   21.43208849   -9.11973810   -2.60603310   -3.56556107
  4.42633851  -11.11135096    4.68336908   11.65200544   -9.19600231
  3.41846945   -6.53522167   -7.51319123  -23.80221782   -8.85406142
  3.33307934  -33.02891551  -21.46410556    4.42386710    2.49546929
 36.49735505   36.58193286   10.86173084  -23.24090365 1804.87316597
 -0.08945924    7.62743680   -4.88366683    5.32184223  -11.40973347
-11.63516555   -4.50667354   16.81649453    4.22134883

I'll keep investigating this problem.

[cschwan]

Here the differences from #61 (comment) again, split up into the invariant mass slices:

 # 12-20
 20.0917284  21.5415290  26.2062340  17.3151163  11.1303845   5.2054212  15.7308334  -6.4114262
 # 20-30
  2.6246604   8.9586122   7.0997364   2.1658015  11.2931941   2.7415876   0.5196463  -4.9652006
 # 30-46
-13.1186615  -2.5735465   1.6872026  -0.6324217  -5.4407937  -0.9900762   0.4802001   8.3537925
 # 46-66
 24.3119193  15.5972107  24.6329875  14.2668021  22.4928512
 16.3522389   8.7413248  12.0952233  16.0033365   1.4860522
 # 66-116
  0.1234022   7.6067015  -6.3578942  12.8108403   3.9752042  -5.0385603
 -3.1768139  21.5422996  -8.2566768  -1.2195133  -4.4875670   4.5444325
-11.4049064   5.2035294  12.4783671 -12.9535187   4.7143987  -8.0494717
 -7.2734901 -23.2834294  -8.3266973   2.5993887 -31.7154030 -23.7096819
  7.3633567   3.2900353  36.8355769  29.4811241  15.9086792 -23.7210822
 # 116-150
-15.7906773 -17.7225639 -10.4428678 -19.8095448 -25.5045082 -13.3545827
-29.8213427  -8.5893566  -7.5328847 -19.7478887

[cschwan]

Note to myself: compare the numbers at LO!

[cschwan]

@enocera I'm finally certain to have a found a proper difference between the APPLgrid and our PineAPPL grid.

Starting from PineAPPL v0.5.0 you can print out the factorization and renormalization grid values that each subgrid uses to interpolate the PDFs, and for our runcards I find results what I'd expect, given that we set

mu = sqrt(Mll^2 + ptll^2),

where Mll and ptll are the observables that we bin in. For instance, for the invariant mass distribution the first bin contains the integration over

• 12 GeV < Mll < 20 GeV and
• 45 GeV < ptll < 55 GeV,

which means the scale choice is bounded by 46 GeV < mu < 59 GeV. With pineappl subgrids --muf <grid> I can read off the corresponding grid points that are in fact used, and they are

35.922, 41.165, 47.351, 54.675, 63.381, 73.772.

Because of the interpolation not only the grid points in the interval [46, 59] are used, but also the two grid points left from the minimum and right of the maximum. So far so good!

For APPLgrid the used grid points are:

81.000, 96.550, 115.700, 139.414, 168.941, 205.921, 252.509, 311.561, 386.886, 483.592

These points are much higher and don't overlap with our points, so my conclusion is that also the chosen scale must be larger than the one chosen for our runcards.

[enocera]

Thanks @cschwan . Looking at Eq.(3.2) of arXiv:1705.00343, I understand that they use pTZ, where the values of ptZ (look at Fig.1) seem compatible to the larger values of the grid points that you find, would you agree?

[cschwan]

Fig. 1 should correspond to the rapidity distribution (YLL) and Fig. 2 should match the invariant-mass distribution (MLL). In Fig. 2 the ptZ values correspond to the ones that we call ptll. Nevertheless I find for the first bin mu < 59 GeV, but the first grid point in the APPLgrid is much higher, mu = 81 GeV.

[enocera]

Sorry @cschwan I take it back. I did the algebra and I agree with your conclusion. Unfortunately, I'd say there's no way to know which values have been used, as we don't have the runcards.

[cschwan]

@enocera shouldn't the runcards be in our external repository, for instance for the first slice here: https://github.com/NNPDF/external/blob/4e842676deada26d882e1932a5ffd53d4b87709e/MCFM-6.8/Bin/Input/ATLASZPT8TEVMDIST-BIN1.DAT?

[marcozaro]

Thanks Christopher, these discrepancies are indeed puzzling, something strange should have ended up into the ApplGrids. I don’t know, we may consider the issue solved, but it would be interesting to understand how they got those strange numbers (there are infinite ways one can screw up a scale, and we would need the code to see what was done)… Let me know if you have any idea cheers, Marco

…

On 23 Feb 2022, at 14:20, Christopher Schwan ***@***.***> wrote: Fig. 1 should correspond to the rapidity distribution (YLL) and Fig. 2 should match the invariant-mass distribution (MLL). In Fig. 2 the ptZ values correspond to the ones that we call ptll. Nevertheless I find for the first bin mu < 59 GeV, but the first grid point in the APPLgrid is much higher, mu = 81 GeV. — Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHECN5BVR3AUHBGPLVMJSTDU4TNLBANCNFSM4TCEE67Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[enocera]

@enocera shouldn't the runcards be in our external repository, for instance for the first slice here: https://github.com/NNPDF/external/blob/4e842676deada26d882e1932a5ffd53d4b87709e/MCFM-6.8/Bin/Input/ATLASZPT8TEVMDIST-BIN1.DAT?

Do you trust them? I don't. Are you sure that the applgrids have been produced with these runcards? I'm not. Are you sure that this line https://github.com/NNPDF/external/blob/4e842676deada26d882e1932a5ffd53d4b87709e/MCFM-6.8/Bin/Input/ATLASZPT8TEVMDIST-BIN1.DAT#L25 is equivalent to choosing sqrt(mll^2+ptll^2)? I'm not.

[enocera]

@enocera Thanks to Marco and Maria we've very likely found the source of disagreement. Maria was able to find the MCFM runcards, in which the scale is set to

sqrt(M^2+pt34^2)

If you read the MCFM documentation (p. 20, table 11) it says that

M = mass of particle 3+4

which I (and also Alberto, who generated the grids) read as being the invariant mass of particles 3 and 4. However, Marco explicitly verified that it's actually the on-shell Z mass weary.

And isn't this the ambiguity?

[marcozaro]

Hi, as far as I can remember Maria also wrote that Guffanti changed this behaviour in order to match what they write in the paper Marco

…

On 23 Feb 2022, at 16:29, Emanuele R. Nocera ***@***.***> wrote: @enocera <https://github.com/enocera> Thanks to Marco and Maria we've very likely found the source of disagreement. Maria was able to find the MCFM runcards, in which the scale is set to sqrt(M^2+pt34^2) If you read the MCFM documentation <https://mcfm.fnal.gov/manual.pdf> (p. 20, table 11) it says that M = mass of particle 3+4 which I (and also Alberto, who generated the grids) read as being the invariant mass of particles 3 and 4. However, Marco explicitly verified that it's actually the on-shell Z mass weary. And isn't this the ambiguity? — Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHECN5BK2INWBO35ZGKRA5DU4T4MVANCNFSM4TCEE67Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[cschwan]

@enocera Thanks to Marco and Maria we've very likely found the source of disagreement. Maria was able to find the MCFM runcards, in which the scale is set to

sqrt(M^2+pt34^2)

If you read the MCFM documentation (p. 20, table 11) it says that

M = mass of particle 3+4

which I (and also Alberto, who generated the grids) read as being the invariant mass of particles 3 and 4. However, Marco explicitly verified that it's actually the on-shell Z mass weary.

And isn't this the ambiguity?

If I did my checks in the past properly, then according to #61 (comment) this shouldn't be able to explain the difference. But obviously the scale is different, so maybe I missed something. I've asked Maria to send me the corresponding emails again, as I've lost my INFN account; then I should be able to redo the check I did in the past.

[enocera]

OK, sorry, I should have read the discussion more carefully.

[cschwan]

Maria sent me her runcards and they are exactly the ones in the repository. I still have to check the scale setting procedure.