Issue when importing fastNLO tables: metadata and flexible-scale choice

[t7phy]

Hi @cschwan, I have been converting some grids from the fastnlo format to the pineappl format, however after conversion, it seems that the name and units of the bin are not being stored in the pineappl file and instead it just lists the name as x1. Any ideas on why that might be happening?

[cschwan]

The CLI doesn't copy fastNLO's metadata, so that's not unexpected. I suppose you need them?

In the meantime you can fix this manually by setting them yourself, using the keys listed here: https://nnpdf.github.io/pineappl/docs/metadata.html. The descriptions are still missing, but hopefully the keys are self-explainatory. The corresponding _tex keys are only needed for pineappl plot.

[t7phy]

Ok, 2 questions: How should the keys be set manually? and Is it possible to add the feature where the metadata is also copied? This would be very helpful as for NNLO Jet grids, we have no option but to take use already computed grids and convert them and since there are too many (each distribution with many bins * many distributions), this becomes a tedious task to manually modify the keys for all of them.

[cschwan]

Ok, 2 questions: How should the keys be set manually?

Sorry, I meant to explain this already in my last comment:

pineappl write --set-key-value x1_label x1 --set-key-value y_label y --set-key-value x1_unit pb <in> <out>

This will load <in>, add the specified key-value pairs (add as many as you need) and writes the result into <out>. For safety reasons <out> can't be an existing file.

If your CLI doesn't have the write subcommand, either update it or use set instead.

and Is it possible to add the feature where the metadata is also copied? This would be very helpful as for NNLO Jet grids, we have no option but to take use already computed grids and convert them and since there are too many (each distribution with many bins * many distributions), this becomes a tedious task to manually modify the keys for all of them.

Agreed.

[t7phy]

Thanks :)

[alecandido]

and Is it possible to add the feature where the metadata is also copied? This would be very helpful as for NNLO Jet grids, we have no option but to take use already computed grids and convert them and since there are too many (each distribution with many bins * many distributions), this becomes a tedious task to manually modify the keys for all of them.

Agreed.

I agree this can be part of the converter, but even for the time being you don't have to do it manually for all the bins and distributions, you can use the PineAPPL primitives and script it (both in Bash and Python).

[cschwan]

Commit ee84ca62765d5087234cb054bce1637b038af8ce converts also fastNLO's metadata. This automatically populates the values of the keys x{1,2,...}_label and y_label. In addition you also get the scenario description from the key fastnlo_scenario. Could you test this and tell me whether this is what you need, @t7phy?

[t7phy]

@cschwan , lots of things in my PC are currently broken so I will try to do it asap, once they are fixed. Just to know, do I just need to follow the installation procedure with cargo again to have this new feature?

[cschwan]

Sorry to hear that, @t7phy! There's no rush on my end so take the time you need.

You need to install pineappl from the master-branch, meaning either you follow the development version installation instructions or, if you've already download the git repository, you update it and run cargo install --path pineappl_cli in it. In any case, don't forget to add --features=fastnlo, otherwise it will complain when you try to convert the grids.

[t7phy]

Hi @cschwan, Thanks for the added feature, its working as needed. There are two things though:

1. there seems to be a minor bug, the units for the kinematics are being printed within the name as opposed to the dedicated brackets for them as shown below:
2. It is not fully clear to me how the cross sections are being displayed, for example if you have a look at the following: left image is from pineappl and right image is from fastnlo, the cross sections in the pineappl one seem to correspond to the NNLO cross sections in the fastnlo, but they only match upto 1 or 2 decimal points. Is that expected, and if so, why is that? Another example is as below: In this case, the correspondence is even worse, and I don't understand why. Any ideas?

[alecandido]

@t7phy, whenever possible, prefer copy-pasting text, rather than pictures of text (especially in the case of tables it'd make it simpler to analyze the data, e.g. taking the ratio of two columns, without having to reproduce them).

[cschwan]

@t7phy:

1. the explanation is that fastNLO doesn't have a notion of units or a very incomplete one: it only knows the unit of the cross section (pb, fb, ...), but as soon as you have a differential cross section, for instance with the units pb/GeV fastNLO will only return pb and omit the /GeV part. The information that it has are the labels you see, and I don't think there's a reliable way of extracting the units from a general fastNLO table.
2. The import subcommand performs a check, and if you don't modify the --accuracy parameter it should only ever write out a converted grid when both tables pass this check and therefore are the same. Did you use the same PDF sets when performing the convolution with pineappl and fnlo-tk-cppread? Try the following: fnlo-tk-cppread <fastNLO table> NNPDF40_nnlo_as_01180 _ LHAPDF and compare the each order with the corresponding ones in pineappl orders <converted grid> NNPDF40_nnlo_as_01180.

[t7phy]

1. the explanation is that fastNLO doesn't have a notion of units or a very incomplete one: it only knows the unit of the cross section (pb, fb, ...), but as soon as you have a differential cross section, for instance with the units pb/GeV fastNLO will only return pb and omit the /GeV part. The information that it has are the labels you see, and I don't think there's a reliable way of extracting the units from a general fastNLO table.

Ok, this is what I had guessed but I just wanted to let you know (in case my guess was wrong).

2. The import subcommand performs a check, and if you don't modify the --accuracy parameter it should only ever write out a converted grid when both tables pass this check and therefore are the same. Did you use the same PDF sets when performing the convolution with pineappl and fnlo-tk-cppread? Try the following: fnlo-tk-cppread <fastNLO table> NNPDF40_nnlo_as_01180 _ LHAPDF and compare the each order with the corresponding ones in pineappl orders <converted grid> NNPDF40_nnlo_as_01180.

So, I didn't touch the --accuracy at all, and when the import was performed, pineappl showed its values' and fastnlo's values as identical (to 10^-14 or 10^-15 accuracy). However, the values that pienappl displays for fastnlo are not the same as what fastnlo displays by itself. I am using the same PDF sets and I tried using the command you mentioned (with the '_ LHAPDF' at the end) but its still the same. I have attached below one of the fastnlo files as an example. Could you see if this issue is replicated if you do the conversion? Maybe that might help.

applfast-h1-incjets-fnlo-arxiv-1611.03421-xsec000.tab.gz

[cschwan]

That's an interesting find. It turns out that:

• this is one of the flexible-scale tables, for which you can vary the functional forms of the renormalization and factorization scale;
• the default functional forms set in the table is printed during import:

  # INFO.    [fastNLOReader::PrintScaleSettings] Renormalization scale chosen to be mu_r^2 = 1^2 * (Q^2 + pTjet^2)/2
  # INFO.    [fastNLOReader::PrintScaleSettings] Factorization scale chosen to be   mu_f^2 = 1^2 * Q^2

• while import uses the default set in the table, fnlo-tk-cppread unconditionally sets the functional form to mur^2 = muf^2 = Q^2. You can vary this choice with yet another parameter, for instance fnlo-tk-cppread applfast-h1-incjets-fnlo-arxiv-1611.03421-xsec000.tab.gz NNPDF40_nnlo_as_01180 _ LHAPDF _ kScale2, but fnlo-tk-cppread doesn't offer an option to select the default value (as given above) nor does it allow to set the renormalization and factorization scale to the values given above.

There isn't anything I can do on the fastNLO side, but I can add an option to change the renormalization/factorization during the import.

[cschwan]

@t7phy with commit a151732e637b18b6b10bb77e6143850d5bfc868d, you can try the following:

pineappl import <table> <grid> <PDF> --fnlo-mur=kScale1 --fnlo-muf=kScale1 --digits-abs=11

This will produce the same numbers as:

fastnlo-tk-cppread <table> <PDF> _ LHAPDF

This should suffice for convincing yourself that these are actually the same numbers, but I suggest not to use any --fnlo-mur or --fnlo-muf if you want to actually use the converted fastNLO tables; without these options the default scale choices will be used, which usually have been chosen for a good reason.

[t7phy]

Thanks @cschwan :)