Closed felixhekhorn closed 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?
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
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?
@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.
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.
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?
@felixhekhorn It's not because it's the EW coupling alpha
and not the QCD alphas
!
@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.
Seems alright :+1: close?
- 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.
Seems alright +1 close?
Thank you for testing, I'm closing it.
@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
I agree to keep out pandas
from pineappl_py
, let's keep as few dependencies as possible
Since we were thinking to dissolve
pineko
and to merge it withfkutils
I was wondering whether we could move the compare script https://github.com/N3PDF/pineko/blob/main/src/pineko/comparator.py insidePineAPPL
- more specific intopineappl 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/16and 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?)