CLI's `convolute` and Python `Grid::convolute_with_one` give different results

[felixhekhorn]

the problem

Calling the CLI pineappl convolute and the Pyhton equivalent pineappl.grid.Grid.convolute_with_one does not yield the same number - the python number is consistent with the result from the raw Vegas integration. This does only happen from one out of two grids that I have - and the two only differ by $\sqrt s$ (i.e. a parameter that effects the coefficient functions, but not the grid generation in any way)

all codes are here

the bad one

the grid:

$ pineappl read --show tab1-ccbar-100TeV.pineappl.lz4 
MaunaKea/IntegrationConfig: verbosity: 0
calls: 50000
warmupCalls: 1000
iterations: 5
warmupIterations: 5
adaptChi2: 1
bins: 250
MaunaKea/IntegrationOutput: result: 2.668271e+10
error: 4.028863e+07
chi2: 7.318209e-01
chi2iter: 0
MaunaKea/PDF: ABMP16_3_nnlo#0
MaunaKea/hadronicS: 1.000000e+10
MaunaKea/lumi_mask: 63
MaunaKea/m2: 2.788900e+00
MaunaKea/nl: 3
MaunaKea/order_mask: 7
MaunaKea/xi: 2.000000e+00
MaunaKea/xiF: 1.000000e+00
MaunaKea/xiR: 1.000000e+00
initial_state_1: 2212
initial_state_2: 2212
pineappl_gitversion: v0.6.3-60-gf00839e
y_label: sigma_tot
y_label_tex: \sigma_{tot}
y_unit: pb

python is good:

$ python tab1.py plot 3 100
[2] > /home/felix/Physik/JYUFI/HQproduction/MaunaKea/Benchmarks/1612.05582/tab1.py(59)plot()
-> xis = []
(Pdb++) central
26.72745381640661
(Pdb++) c
sigma(ccbar+X, sqrt(S)=100TeV) = 26.7 ± 20.8_sc ± 1.4_pdf

the CLI is wrong:

$ pineappl --silence-lhapdf convolute tab1-ccbar-100TeV.pineappl.lz4 ABMP16_3_nnlo 
b x1   sigma_tot  
  []      [pb]    
-+-+-+------------
0 0 1 2.4864864e10

the good one

the grid:

$ pineappl read --show tab1-ccbar-14TeV.pineappl.lz4 
MaunaKea/IntegrationConfig: verbosity: 0
calls: 50000
warmupCalls: 1000
iterations: 5
warmupIterations: 5
adaptChi2: 1
bins: 250
MaunaKea/IntegrationOutput: result: 7.613465e+09
error: 8.385665e+06
chi2: 6.559269e-01
chi2iter: 1
MaunaKea/PDF: ABMP16_3_nnlo#0
MaunaKea/hadronicS: 1.960000e+08
MaunaKea/lumi_mask: 63
MaunaKea/m2: 2.788900e+00
MaunaKea/nl: 3
MaunaKea/order_mask: 7
MaunaKea/xi: 2.000000e+00
MaunaKea/xiF: 1.000000e+00
MaunaKea/xiR: 1.000000e+00
initial_state_1: 2212
initial_state_2: 2212
pineappl_gitversion: v0.6.3-60-gf00839e
y_label: sigma_tot
y_label_tex: \sigma_{tot}
y_unit: pb

python is good:

$ python tab1.py plot 3 14
[2] > /home/felix/Physik/JYUFI/HQproduction/MaunaKea/Benchmarks/1612.05582/tab1.py(59)plot()
-> xis = []
(Pdb++) central
7.613817798111711
(Pdb++) c
sigma(ccbar+X, sqrt(S)=14TeV) = 7.6 ± 4.6_sc ± 0.3_pdf

the CLI is good as well:

$ pineappl --silence-lhapdf convolute tab1-ccbar-14TeV.pineappl.lz4 ABMP16_3_nnlo 
b x1   sigma_tot 
  []     [pb]    
-+-+-+-----------
0 0 1 7.6137453e9

EDIT: actually, even here the numbers only match with 3/4 digits, although the implementation should be identical

[cschwan]

The problem is that you're outside of the validity of the PDF set, or in other words that you're testing LHAPDF extrapolation feature. In ABMP16_3_nnlo's info file you can see:

XMin: 1e-07

While debugging this problem I noticed that some PDF values are smaller than this minimum, and the difference then comes from this code block:

https://github.com/NNPDF/pineappl/blob/f00839ecbf8516da69572d9ecfba7f8dafdb944f/pineappl_cli/src/helpers.rs#L159-L167

I suppose what you'd like would be to disable this feature just for testing purposes, wouldn't you?

[felixhekhorn]

I see - it was just unexpected for me to have the CLI and python return two different results, but I forgot the CLI is not just convolute_with_one but also additional checks (such as this one).

As for the matter itself: maybe we could add a switch to the CLI to turn off the additional checks - on Grid::convolute_with_one-level (both Rust and Pyhton) there is nothing to be done since at that point Rust receives a callable and can not judge it's validity ... maybe another thing could be to provide a Grid::convolute_with_one in python which takes a Python LHAPDF::PDF object, which we could check (or regularize) if needs be ...

not sure we have to do something, so you can also just close as "feature not a bug", if you think so - it is good to be aware though

[cschwan]

You're right that this is surprising behavior - which is almost never good - and to remedy that I added a global option --allow-extrapolation in commit d755b1adcf428dc5f64df3bf40896693f247a51a. With that option present, for instance in

pineappl --allow-extrapolation convolute tab1-ccbar-14TeV.pineappl.lz4 ABMP16_3_nnlo

the CLI returns the same value as the Python interface:

b x1   sigma_tot  
  []      [pb]    
-+-+-+------------
0 0 1 2.6727454e10

This has the general advantage in that now we have an easy test of whether an observable goes significantly into the extrapolation region - just compare the values with both settings.