Fktables for NLO theory

[andreab1997]

This is the NLO eqiuivalent of NNPDF/fktables#5

We list here the Fktables which we cannot compute at the moment for the central NLO theory (208):

• jets (so needs Composite Output eko#105)
  • ATLAS_2JET_7TEV_R06
  • ATLAS_1JET_8TEV_R06
  • CMS_1JET_8TEV
  • CMS_2JET_7TEV
• missing grids
  • ATLAS_WCHARM_WP_DIFF_7TEV (take from dom /media/Fk/fktables/data/appl_subgrids)
  • ATLAS_WCHARM_WM_DIFF_7TEV (take from dom /media/Fk/fktables/data/appl_subgrids)
  • CMSWCHARMTOT (Write the yamldb for the composition CMSWCHARM_WP and CMSWCHARM_WM with operand "add", take the two grids from /media/Fk/fktables/data/appl_subgrids )
  • CMSWCHARMRAT (same of previous but with operands "ratio")
  • CMS_WCHARM_DIFF_UNNORM_13TEV (same as the previous but with operand "add" and different grids: CMS_WCHARM_13TEV_WMC and CMS_WCHARM_13TEV_WPCB)
• We miss ren sv:
  • ATLAS_TOPDIFF_DILEPT_8TEV_TTRAPNORM (because we are missing ren sv for CMSTTBARTOT8TEV-TOPDIFF8TEVTOT, coming from Sherpa)
  • ATLAS_TTBARTOT_13TEV_FULLLUMI (because we are missing ren sv for ATLAS_TTBARTOT_13TEV_FULLLUMI-TOPDIFF13TEVTOT, coming from Sherpa)
  • ATLASTTBARTOT7TEV (because of ATLASTTBARTOT7TEV-TOPDIFF7TEVTOT, coming from Sherpa)
  • ATLASTTBARTOT8TEV (because of ATLASTTBARTOT8TEV-TOPDIFF8TEVTOT, this should be the same as CMSTTBARTOT8TEV-TOPDIFF8TEVTOT)
  • ATLAS_WM_JET_8TEV_PT ( because of ATLAS_WM_JET_8TEV_PT-atlas-atlas-wjets-arxiv-1711.03296-xsec003 which is coming from ploughshare)
  • ATLAS_WP_JET_8TEV_PT ( because of ATLAS_WP_JET_8TEV_PT-atlas-atlas-wjets-arxiv-1711.03296-xsec002 which is coming from ploughshare)
  • ATLASZPT8TEVMDIST (it is coming from MCFM)
  • ATLASZPT8TEVYDIST (it is coming from MCFM)
  • CMS_1JET_8TEV (coming from NLOjet++)
  • CMSTOPDIFF8TEVTTRAPNORM (because of CMSTOPDIFF8TEVTTRAPNORM-TOPDIFF8TEVTTRAP, coming from Sherpa and total cross-section see above)
  • CMSTTBARTOT13TEV (because of CMSTTBARTOT13TEV-TOPDIFF13TEVTOT, coming from Sherpa)
  • CMSTTBARTOT8TEV (because of CMSTTBARTOT8TEV-TOPDIFF8TEVTOT, coming from Sherpa)
  • CMSTTBARTOT7TEV (because of CMSTTBARTOT7TEV-TOPDIFF7TEVTOT, coming from Sherpa)
  • CMSZDIFF12 (coming from MCFM)
  • ATLAS_WCHARM_WP_DIFF_7TEV
  • ATLAS_WCHARM_WM_DIFF_7TEV
  • CMSWCHARMTOT
  • CMSWCHARMRAT
  • CMS_WCHARM_DIFF_UNNORM_13TEV
• FTDY (needs VRAP)
  • DYE886R_dw_ite
  • DYE886P
  • DYE906R_dw_ite
• Things to check:
  • D0ZRAP_40 (working for NNLO, check the bug)
  • D0WMASY
  • ATLASWZRAP36PB
  • ATLASDY2D8TEV
  • ATLAS_DY_2D_8TEV_LOWMASS
  • ATLASPHT15_SF (two bins for each FKtable are correct the others are not)
  • CMSWEASY840PB
  • CMSWMASY47FB
  • CMSWMU8TEV
• Things with a conjectured solution
  • ATLAS_TTB_DIFF_8TEV_LJ_TRAPNORM (maybe just a 2.0 conversion factor)
  • ATLAS_TTB_DIFF_8TEV_LJ_TTRAPNORM (same)
  • CDFZRAP_NEW (see issue NNPDF/fktables#17)
  • CMS_TTBAR_2D_DIFF_MTT_TRAP_NORM (this is actually correct NNPDF/fktables#5 )

[andreab1997]

@cschwan @enocera Could you please have a look to the grids with the missing ren scale variations of the list above (third list)? How should we proceed?

For example we are missing lots of total cross sections for TTBAR which are not in the pinecard repo. However the repo provides differential cross-sections. Should we add the missing?

[cschwan]

The top-pair production grids should be available in https://github.com/NNPDF/pineapplgrids, one of them possibly in a branch. All other would have to be implemented in https://github.com/NNPDF/runcards.

[andreab1997]

The top-pair production grids should be available in https://github.com/NNPDF/pineapplgrids, one of them possibly in a branch. All other would have to be implemented in https://github.com/NNPDF/runcards.

Thank you very much. So the grids in https://github.com/NNPDF/pineapplgrids contain ren scale variations?

[felixhekhorn]

@cschwan for the elements in the fifth list above ("things to check") we don't have any clear clue on what the problem is ... some of the bins (but not all) are matching and others are completely off. Do you see any common pattern for the datasets? @andreab1997 checked that the ekos are fine and also the grids are fine (as we knew from before). So now we're suspecting maybe pineko or pineappl (i.e. Grid::convolute_eko) to have a breaking change somewhere (tentatively between May and now). We concluded this from a bunch of files at dom for which instead the convolution was working (and which got computed before that date). E.g. NNPDF/pineappl#103 would fall into this time, do you think there is a possibility that this broke the convolution?

As for pineko: there is actually almost nothing, but the Grid::convolute_eko call, so while it is still possible the bug might be there, I'd say it is unlikely ...

[cschwan]

Thank you very much. So the grids in https://github.com/NNPDF/pineapplgrids contain ren scale variations?

They should! You can explicitly check this if you run the CLI using pineappl obl --orders [grid] on them, and this should show the logmur and logmuf orders. Let me know if there are any problems!

[cschwan]

[..] We concluded this from a bunch of files at dom for which instead the convolution was working (and which got computed before that date). E.g. N3PDF/pineappl#103 would fall into this time, do you think there is a possibility that this broke the convolution?

This could well be, yet another reason to have a unit test for this ...

I can test this, but I'm afraid I won't be able to this week. If you want to test this yourself, try

git checkout 954aadfbf3878d0f0583c820b3f5326462a12478

which will checkout PineAPPL before the changes. I hope that the Python API still works.

[andreab1997]

[..] We concluded this from a bunch of files at dom for which instead the convolution was working (and which got computed before that date). E.g. N3PDF/pineappl#103 would fall into this time, do you think there is a possibility that this broke the convolution?

This could well be, yet another reason to have a unit test for this ...

I can test this, but I'm afraid I won't be able to this week. If you want to test this yourself, try

git checkout 954aadfbf3878d0f0583c820b3f5326462a12478

which will checkout PineAPPL before the changes. I hope that the Python API still works.

I have done some tests and I can add some details. As expected, I was able to produce the correct Fktables with older versions of pineko, eko and pineappl. In particular I used pineko==0.1.1, eko==0.8.5 and pineappl==0.5.2. @felixhekhorn @cschwan Do this suggest something to you?
Take into account that with pineko==0.1.2 and pineappl==0.5.4 I got again the wrong results.

[alecandido]

You should be able to do the same with every version of eko. Please, try the latest one.

[andreab1997]

You should be able to do the same with every version of eko. Please, try the latest one.

Yes I can try but pineko==0.1.1 requires eko==0.9.0 at most. Anyway, It is not a problem most likely.

[alecandido]

Apart from what the package require, you should be able to use a newer version (if not through Poetry, manually).

Might be that something is broken, but something is not everything. Or do you know that there is something required in pineko==0.1.1 that is not any longer there in eko==0.10.x?

[andreab1997]

Apart from what the package require, you should be able to use a newer version (if not through Poetry, manually).

Might be that something is broken, but something is not everything. Or do you know that there is something required in pineko==0.1.1 that is not any longer there in eko==0.10.x?

I don't know, most likely nothing is broken. Indeed I launched the job and it did not crash until now. It was just a possibility :)

[andreab1997]

Apart from what the package require, you should be able to use a newer version (if not through Poetry, manually).

Might be that something is broken, but something is not everything. Or do you know that there is something required in pineko==0.1.1 that is not any longer there in eko==0.10.x?

I can confirm that even with eko==0.10.2, with the older versions of pineko and pineappl, I can obtain the correct results.