NNPDF / pineappl

PineAPPL is not an extension of APPLgrid
https://nnpdf.github.io/pineappl/
GNU General Public License v3.0
12 stars 3 forks source link

Fix and extend `pineappl diff` #112

Closed felixhekhorn closed 2 years ago

felixhekhorn commented 2 years ago

Since we were thinking to dissolve pineko and to merge it with fkutils I was wondering whether we could move the compare script https://github.com/N3PDF/pineko/blob/main/src/pineko/comparator.py inside PineAPPL - more specific into pineappl diff since the functionality is very similar. The only addition is the restriction of orders onto the process level grid, something that proved very useful in the context of https://github.com/NNPDF/fktables/issues/16

and I would like diff to retain the binning information (x,Q2 limits etc.) (which I believe at the moment he is not doing) (maybe by a flag?)

cschwan commented 2 years ago

The binning information is printed, but I can add a flag that selects a specific subset of orders. For your purposes, the comparison of FK tables and PineAPPL grids, the flag --ignore-orders should do the trick. Can you confirm that?

felixhekhorn commented 2 years ago

but --ignore-orders is not exactly what we need since in this case I'm comparing a grid, with an complicated order structure, against a FK-table, with a trivial order structure and I want to impose a specific restriction (LO, NLO, NNLO) only on one of them

felixhekhorn commented 2 years ago

There is even something strange happening ...

$ pineappl diff data/appl_subgrids/LHCBWZMU8TEV-LHCBWZMU8TEV_Z_yZ.pineappl.lz4 data/appl_subfktables/200-LHCBWZMU8TEV-LHCBWZMU8TEV_Z_yZ.pineappl.lz4 NNPDF40_nnlo_as_01180
LHAPDF 6.4.0 loading /usr/share/lhapdf/LHAPDF/NNPDF40_nnlo_as_01180/NNPDF40_nnlo_as_01180_0000.dat
NNPDF40_nnlo_as_01180 PDF set, member #0, version 1
--- Orders: O(as^1) 
+++ Orders: 

bin     x1                O(as^0 a^0)          
---+-----+-----+-----------+-----------+-------
  0     2 2.125 6.8010121e3 6.8010121e3 0.000e0
  1 2.125  2.25 1.9663405e4 1.9663405e4 0.000e0
  2  2.25 2.375 3.1947439e4 3.1947439e4 0.000e0
  3 2.375   2.5 4.3152866e4 4.3152866e4 0.000e0
  4   2.5 2.625 5.2894455e4 5.2894455e4 0.000e0
  5 2.625  2.75 6.0557660e4 6.0557660e4 0.000e0
  6  2.75 2.875 6.6182074e4 6.6182074e4 0.000e0
  7 2.875     3 6.8844593e4 6.8844593e4 0.000e0
  8     3 3.125 6.8336321e4 6.8336321e4 0.000e0
  9 3.125  3.25 6.5013185e4 6.5013185e4 0.000e0
 10  3.25 3.375 5.5802031e4 5.5802031e4 0.000e0
 11 3.375   3.5 4.2614414e4 4.2614414e4 0.000e0
 12   3.5 3.625 3.0305990e4 3.0305990e4 0.000e0
 13 3.625  3.75 1.9447633e4 1.9447633e4 0.000e0
 14  3.75 3.875 1.0979815e4 1.0979815e4 0.000e0
 15 3.875     4 5.1478524e3 5.1478524e3 0.000e0
 16     4  4.25 1.1774176e3 1.1774176e3 0.000e0
 17  4.25   4.5 4.1628581e1 4.1628581e1 0.000e0
Thanks for using LHAPDF 6.4.0. Please make sure to cite the paper:
  Eur.Phys.J. C75 (2015) 3, 132  (http://arxiv.org/abs/1412.7420)

$ pineappl diff data/appl_subgrids/LHCBWZMU8TEV-LHCBWZMU8TEV_Z_yZ.pineappl.lz4 data/appl_subfktables/200-LHCBWZMU8TEV-LHCBWZMU8TEV_Z_yZ.pineappl.lz4 NNPDF40_nnlo_as_01180 --ignore-orders
LHAPDF 6.4.0 loading /usr/share/lhapdf/LHAPDF/NNPDF40_nnlo_as_01180/NNPDF40_nnlo_as_01180_0000.dat
NNPDF40_nnlo_as_01180 PDF set, member #0, version 1
bin     x1                                       
---+-----+-----+-----------+-----------+---------
  0     2 2.125 8.3774944e3 8.3708888e3  7.891e-4
  1 2.125  2.25 2.3991570e4 2.3976037e4  6.478e-4
  2  2.25 2.375 3.8794533e4 3.8765112e4  7.590e-4
  3 2.375   2.5 5.1959290e4 5.1916341e4  8.273e-4
  4   2.5 2.625 6.3006295e4 6.2966054e4  6.391e-4
  5 2.625  2.75 7.1508712e4 7.1463828e4  6.281e-4
  6  2.75 2.875 7.7532656e4 7.7468442e4  8.289e-4
  7 2.875     3 7.9982100e4 7.9925813e4  7.042e-4
  8     3 3.125 7.8606231e4 7.8557562e4  6.195e-4
  9 3.125  3.25 7.3668223e4 7.3615791e4  7.122e-4
 10  3.25 3.375 6.3259898e4 6.3218424e4  6.560e-4
 11 3.375   3.5 4.9135429e4 4.9112598e4  4.649e-4
 12   3.5 3.625 3.5266924e4 3.5245406e4  6.105e-4
 13 3.625  3.75 2.2854426e4 2.2837074e4  7.598e-4
 14  3.75 3.875 1.2962689e4 1.2956276e4  4.949e-4
 15 3.875     4 6.1391384e3 6.1364501e3  4.381e-4
 16     4  4.25 1.4270286e3 1.4268249e3  1.428e-4
 17  4.25   4.5 5.1549571e1 5.1591300e1 -8.088e-4
Thanks for using LHAPDF 6.4.0. Please make sure to cite the paper:
  Eur.Phys.J. C75 (2015) 3, 132  (http://arxiv.org/abs/1412.7420)

how can it be, that the FK-table changes - there should be only one order ... or on the other hand, how can the grid contain a alpha^0 alpha_s^0 entry?

cschwan commented 2 years ago

@felixhekhorn This is clearly a bug, because if we take the first output seriously, both grids are exactly the same - which they clearly aren't.

cschwan commented 2 years ago

I've fixed the problem in commit 5fcbf283c899f101d35925dad89e65d88c455afa. Your second output is unchanged, whereas the first becomes:

--- Orders: O(as^1) 
+++ Orders: 

bin     x1                 O(as^0 a^0)           
---+-----+-----+-----------+-----------+---------
  0     2 2.125 6.8010121e3 8.3708888e3 -1.875e-1
  1 2.125  2.25 1.9663405e4 2.3976037e4 -1.799e-1
  2  2.25 2.375 3.1947439e4 3.8765112e4 -1.759e-1
  3 2.375   2.5 4.3152866e4 5.1916341e4 -1.688e-1
  4   2.5 2.625 5.2894455e4 6.2966054e4 -1.600e-1
  5 2.625  2.75 6.0557660e4 7.1463828e4 -1.526e-1
  6  2.75 2.875 6.6182074e4 7.7468442e4 -1.457e-1
  7 2.875     3 6.8844593e4 7.9925813e4 -1.386e-1
  8     3 3.125 6.8336321e4 7.8557562e4 -1.301e-1
  9 3.125  3.25 6.5013185e4 7.3615791e4 -1.169e-1
 10  3.25 3.375 5.5802031e4 6.3218424e4 -1.173e-1
 11 3.375   3.5 4.2614414e4 4.9112598e4 -1.323e-1
 12   3.5 3.625 3.0305990e4 3.5245406e4 -1.401e-1
 13 3.625  3.75 1.9447633e4 2.2837074e4 -1.484e-1
 14  3.75 3.875 1.0979815e4 1.2956276e4 -1.525e-1
 15 3.875     4 5.1478524e3 6.1364501e3 -1.611e-1
 16     4  4.25 1.1774176e3 1.4268249e3 -1.748e-1
 17  4.25   4.5 4.1628581e1 5.1591300e1 -1.931e-1

That compares the LO contribution of the left grid with the FK table, which by accident is the same order, because the converted APPLgrids set the power of alpha at LO to zero.

felixhekhorn commented 2 years ago

That compares the LO contribution of the left grid with the FK table, which by accident is the same order, because the converted APPLgrids set the power of alpha at LO to zero.

stupid question: isn't this a problem under evolution? - now, it can not be, because otherwise we would have noticed already, but can you tell me again why?

cschwan commented 2 years ago

@felixhekhorn It's not because it's the EW coupling alpha and not the QCD alphas!

cschwan commented 2 years ago

@felixhekhorn In commit df89a23344a4ba523fe2de40ff896de2a8d5ab76 I changed the behaviour of pineappl diff slightly to fit our needs. Could you have a look at it? It should cover at least two cases:

1) compare a converted APPLgrid/fastNLO table with a PineAPPL grid generated from us: pineappl diff --ignore-lumis --orders2=a2,a2as1 appl-converted.pineappl mg5-generated.pineappl. In that case the luminosities and orders will be different because EW corrections are present in our grids. We therefore must ignore the difference in the lumis (--ignore-lumis), and from our second grid we select the highest orders in QCD with --orders2=a2,a2as1. In practice this doesn't always work yet because the converted grid has the wrong alpha order. 2) compare an FK table with another grid, possibly excluding EW corrections: pineappl diff --ignore-lumis --ignore-orders --orders2=a2,a2as1 fk-table.pineappl mg5-generated.pineappl. Here we need to add --ignore-orders because they are completely different among the two grids.

felixhekhorn commented 2 years ago

Seems alright :+1: close?

cschwan commented 2 years ago
  1. In practice this doesn't always work yet because the converted grid has the wrong alpha order.

This'll be fixed in https://github.com/N3PDF/pineappl/issues/113.

cschwan commented 2 years ago

Seems alright +1 close?

Thank you for testing, I'm closing it.

felixhekhorn commented 2 years ago

@cschwan I was about to delete the function in pineko, but then I realized that it is the only way to envoke that in python - I guess we just keep it where it is, right? the other option would be to move it into pineappl_py, but that would introduce pandas as a dependency there and that we maybe want to avoid ... cc @AleCandido

alecandido commented 2 years ago

I agree to keep out pandas from pineappl_py, let's keep as few dependencies as possible