Closed cschwan closed 2 years ago
Just a spare comment: I have no better proposal, but personally I find Q15
a bit confusing.
It was not clear to me that it meant q = 1.5
...
Just a spare comment: I have no better proposal, but personally I find
Q15
a bit confusing. It was not clear to me that it meantq = 1.5
...
Agreed. If you have a better suggestion, I'd be happy to adopt it!
Just a spare comment: I have no better proposal, but personally I find
Q15
a bit confusing. It was not clear to me that it meantq = 1.5
...Agreed. If you have a better suggestion, I'd be happy to adopt it!
Do we need this name tag? it was not present in the old name and I wonder how quickly it will change (the xgrid isn't part of the name either and is at least equally important ...)
@felixhekhorn good point. Do you know where the old positivity grids are and how they are named? Maybe we can add the NNPDF version, when they were first added, to the positivity dataset name. So something like NNPDF_POS_CHARM_40
; then we know this is the positivity dataset used in 4.0. But I don't have a strong opinion about this, we should just have something more descriptive than NNPDF_POS_CHARM
.
Another point: does the q
parameter in the runcard coincide with the fitting scale? Because the Grid
that we generate happens to be also an FkTable
(from PineAPPL's point of view, without evolution).
Another point: does the
q
parameter in the runcard coincide with the fitting scale? Because theGrid
that we generate happens to be also anFkTable
(from PineAPPL's point of view, without evolution).
I believe it's not required: indeed Tommaso is about to propose to raise a bit the scale at which positivity is imposed.
For sure you have to specify explicitly, but you can assume that evolution is always taking place (if it's trivial, then it is eko
's responsibility to provide a trivial evolution operator).
Another point: does the
q
parameter in the runcard coincide with the fitting scale? Because theGrid
that we generate happens to be also anFkTable
(from PineAPPL's point of view, without evolution).
@felixhekhorn good point. Do you know where the old positivity grids are and how they are named? Maybe we can add the NNPDF version, when they were first added, to the positivity dataset name. So something like
NNPDF_POS_CHARM_40
; then we know this is the positivity dataset used in 4.0.
But I don't have a strong opinion about this, we should just have something more descriptive than
NNPDF_POS_CHARM
.
I see your point, but I've no good suggestion ...
Another point: does the
q
parameter in the runcard coincide with the fitting scale? Because theGrid
that we generate happens to be also anFkTable
(from PineAPPL's point of view, without evolution).* No, because the 4.0 fitting scale is 1.65 GeV * even more this scale would be a true problem in the old setup as it is below the charm threshold (mc = 1.51 GeV)
We could add some metadata that specifies the 'positivity scale`. The fit can then check for potential pitfalls.
MVP
Most Valuable Positivity
But I don't have a strong opinion about this, we should just have something more descriptive than NNPDF_POS_CHARM.
Why is NNPDF_POS_CHARM
not descriptive enough?
I would not add the value of Q
to the name because it can be the case that for different theories we want to use a different Q but conceptually the positivity is the same so I would like to be able to compare NNPDF_POS_CHARM
for fits A
and B
without having to look for scales or anything.
We could add some metadata that specifies the 'positivity scale`. The fit can then check for potential pitfalls.
exactly
We could add some metadata that specifies the 'positivity scale`. The fit can then check for potential pitfalls.
Actually, grid level this information is present (because is the scale contained in the subgrid). We just need to make sure the information is propagated down to FkTables, where it would be flushed by evolution.
We could add some metadata that specifies the 'positivity scale`. The fit can then check for potential pitfalls.
Actually, grid level this information is present (because is the scale contained in the subgrid). We just need to make sure the information is propagated down to FkTables, where it would be flushed by evolution.
we can just add this here: https://github.com/NNPDF/runcards/blob/ecd40ef995b3f2f06257a448a4f5ec7fafe21539/runcardsrunner/external/positivity.py#L73
we can just add this here:
For the easiness of parsing, I would add a separate key with a single float. Everything in PineAPPL metadata is string based, so in that case, to achieve a simple enough result, you should turn that value into a JSON object -> better a separate key.
We could add some metadata that specifies the 'positivity scale`. The fit can then check for potential pitfalls.
Actually, grid level this information is present (because is the scale contained in the subgrid). We just need to make sure the information is propagated down to FkTables, where it would be flushed by evolution.
This scale is implicitly contained in Grid
(the scale of the grid is the positivity scale), but the evolution changes the scale to the fitting scale and then the positivity scale is lost, so we'd need to put this into metadata.
... on the other hand it will be contained in the runcard
metadata which is also yaml. This is still missing though.
Commit 2b9de22aa3db7cf4c413fb4d41f82dbdabdaf5bb writes the complete runcard as a JSON string into the metadata just like yadism, and therefore automatically contains the positivity scale q
.
What's finally left is to implement all the positivity datasets themselves, so
POSF2U
: ?POSF2DW
: ?POSF2S
: ?POSFLL
: ?POSDYU
: Drell-Yan ...?POSDYD
: Drell-Yan ...?POSDYS
: Drell-Yan ...?POSF2C
: ?POSXUQ
: up quarkPOSXUB
: anti-up quarkPOSXDQ
: down quarkPOSXDB
: anti-down quarkPOSXSQ
: strange quarkPOSXSB
: anti-strange quarkPOSXGL
: gluonHow can I find out what the other datasets are? What are the x
grid values? What's the q
value?
All POSX...
are just PDF flavors, those are as simple as the one you implemented.
All POS2F...
are actually DIS structure functions. Exactly which ones God only knows (or who implemented them last time)...
About DY
, I know nothing...
About the kinematics (for all of them): I had a look in the 4.0 paper for xgrid
and Q2
value, but I found nothing. Maybe we should ask in Amsterdam (I'll do it, if you remind me... email is fine, or I can try to put a memo on the phone...), otherwise we can just send an email to the mailing list.
P.S.: you can try to have a look at Tommaso's PhD thesis, he implemented positivity in 4.0. Otherwise we can invoke @scarlehoff help...
Concerning positivity constraints on DIS structure functions and DY cross sections, I suggest that you have a look at Sect. 3.2.3 in https://arxiv.org/pdf/1410.8849.pdf, and in particular at Eqs.(14). As for the kinematics, this is defined in https://github.com/NNPDF/nnpdf/blob/master/buildmaster/filters/POS.cc, for the number of data points in the POS*
files here https://github.com/NNPDF/nnpdf/tree/master/buildmaster/meta
So, for instance, POSF2U
is the contribution from u and ubar PDFs to the DIS structure function F2; POSFLL
is the contribution from all light quark and gluon PDFs to the DIS structure function FL; POSDYU
is the contribution of the u*ubar PDFs to the DY differential cross-section.
And please note that in positivity constaints like POSXUQ
you really need to consider x*PDF, not just the PDF.
And please note that in positivity constaints like
POSXUQ
you really need to consider x*PDF, not just the PDF.
Thanks @enocera, this might be wrong in the current implementation. But that'll be the first thing that I'll try when comparing old against new tables.
Concerning positivity constraints on DIS structure functions and DY cross sections, I suggest that you have a look at Sect. 3.2.3 in https://arxiv.org/pdf/1410.8849.pdf, and in particular at Eqs.(14). As for the kinematics, this is defined in https://github.com/NNPDF/nnpdf/blob/master/buildmaster/filters/POS.cc, for the number of data points in the
POS*
files here https://github.com/NNPDF/nnpdf/tree/master/buildmaster/meta
Perfect, I think that's all I need to know!
Incidentally, the FK tables for the DY positivity constraints are generated in the fixed-target configuration using APFEL. Therefore I'm not sure how you're going to replace them.
But I don't have a strong opinion about this, we should just have something more descriptive than NNPDF_POS_CHARM.
Why is
NNPDF_POS_CHARM
not descriptive enough?
We might want to change the x
grid in a future fit. Right now, I can see that there are 20 x
points which don't agree with our 50 default grid points that both Madgraph5_aMC@NLO and yadism choose. In that case the file positivity.yaml
will be different and I'd consider that a different 'positivity observable', which would also be visible in validphys. Does that make sense to you, @scarlehoff?
I see. I guess I would argue we want to have the same default grids as Madgraph and yadism and set that as the NNPDF_POS_CHARM
and have some transitional names in the middle if we want.
It is different from the current positivity observable but it will be always the same from now on.
Incidentally, the FK tables for the DY positivity constraints are generated in the fixed-target configuration using APFEL. Therefore I'm not sure how you're going to replace them.
@enocera ~where do you see this?~ It's written in the paper you linked above. I think that means we have a job for yadism @felixhekhorn @AleCandido!
@cschwan In the apfelcomb database
Incidentally, the FK tables for the DY positivity constraints are generated in the fixed-target configuration using APFEL. Therefore I'm not sure how you're going to replace them.
@enocera where do you see this?
In the apfelcomb database e.g. https://github.com/NNPDF/apfelcomb/blob/f49871435792bff1e269d524c3e6861aa6dd3e28/db/apfelcomb.dat#L630
We might want to change the
x
grid in a future fit. Right now, I can see that there are 20x
points which don't agree with our 50 default grid points that both Madgraph5_aMC@NLO and yadism choose. In that case the filepositivity.yaml
will be different and I'd consider that a different 'positivity observable', which would also be visible in validphys. Does that make sense to you, @scarlehoff?
While I understand that we may want to change the x
grid in a future fit, I'd like to clarify that, for the DY positivity observable we have 20 x
points (where x
is the momentum fraction in the PDF - and the set of x
values are those on which the positivty constraint is checked) but then we have 40 x
interpolation points in the FK table, see https://github.com/NNPDF/apfelcomb/blob/f49871435792bff1e269d524c3e6861aa6dd3e28/db/apfelcomb.dat#L802. Which x
are you referring to @cschwan , if I may ask?
We might want to change the
x
grid in a future fit. Right now, I can see that there are 20x
points which don't agree with our 50 default grid points that both Madgraph5_aMC@NLO and yadism choose. In that case the filepositivity.yaml
will be different and I'd consider that a different 'positivity observable', which would also be visible in validphys. Does that make sense to you, @scarlehoff?While I understand that we may want to change the
x
grid in a future fit, I'd like to clarify that, for the DY positivity observable we have 20x
points (wherex
is the momentum fraction in the PDF - and the set ofx
values are those on which the positivty constraint is checked) but then we have 40x
interpolation points in the FK table, see https://github.com/NNPDF/apfelcomb/blob/f49871435792bff1e269d524c3e6861aa6dd3e28/db/apfelcomb.dat#L802. Whichx
are you referring to @cschwan , if I may ask?
What I meant was the x
grid values of the interpolation grid, because it is beneficial for the speed of the fit for that be the same across all/most datasets (@scarlehoff correct me if I'm wrong). For some positivity datasets where we simply have the xf(x)
where x
conincides with the momentum fraction, of course, but for DY positivity observables that might be slightly different, but I'm not interested in that for this exercise. Apart from the previously mentioned point we simply have to reproduce the old grids!
@enocera where can I get the positivity grids for each of the flavours? Do we have them in a form before evolution?
However, consider that for 4.0 replacement we want to force whole PDFs positivity, but later we might want to impose positivity only at large x. (This is simple, we simply make 0 instead of Kronecker delta the entries we're not interested in).
For POSF...
this can be implemented as yadism
observable.
About FTDY of course we can do nothing, and as for all the other FTDY observables, we'll keep using old FkTables, up to FTDY provider replacement.
By the way, how does positivity work when scales are varied? Are they also varied in the positivity grids? Would that make sense?
Just for the record: POSF2DW
is down-like F2: https://github.com/NNPDF/nnpdf/blob/001550dde517f7125a67ed60431c42a51403ba49/buildmaster/meta/POSF2DW.yaml (for whatever reason)
By the way, how does positivity work when scales are varied? Are they also varied in the positivity grids? Would that make sense?
NNPDF never fits scale varied theories, so they are only used to construct the theory covmat (and that one has no contribution from pseudo-observables, I guess).
@enocera where can I get the positivity grids for each of the flavours? Do we have them in a form before evolution?
Do you mean FK tables? These are available in each theory along with all other FK tables.
Do you mean FK tables? These are available in each theory along with all other FK tables.
I believe @cschwan really meant grids in the sense of PineAPPL grids (or in this case APPLgrids).
The problem is that they were all generated with APFEL, meaning that they were never dumped in the middle, evolution was applied online. There has never existed anything like a DIS grid before PineAPPL (or FTDY grid, but that is still lacking). As Valerio pointed out once, APFEL is actually computing some kind of grids (otherwise it would be impossible to get FkTables), but they are always kept in memory.
Note to myself: the theories are stored on the CERN server (look at the NNPDF wiki, 'storage servers'), at /eos/user/n/nnpdf/www/tables/
.
Actually, I'd say that vp
downloads its theories from here: https://nnpdf.web.cern.ch/nnpdf/tables/
Is it the same?
@cschwan @AleCandido @felixhekhorn I would like to send a fit with pineko-positivities tomorrow so that it is ready for Amsterdam. Are they ready? (if not I'll do a fit with the old positivities)
@cschwan @AleCandido @felixhekhorn I would like to send a fit with pineko-positivities tomorrow so that it is ready for Amsterdam. Are they ready? (if not I'll do a fit with the old positivities)
If you want to have PDF positivity, you just need to plug yourself the xgrid
and the scale, but the runner is ready.
For everything else, the answer is just no.
P.S.: consider that half of the observables used are FTDY, so the ability of completely generating new positivity FkTables is strictly dependent on the implementation of a FTDY provider
Ok, then I'll do a fit with the old positiv
@scarlehoff I also have to test this, which means comparing the old FK tables with the grids generated using this generator, but for that I need https://github.com/N3PDF/pineappl/issues/70, and that'll take a while ...
Using the FK table importer from https://github.com/N3PDF/pineappl/issues/70 it seems that the generator developed in this branch works:
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 2.4475749e0 2.4477671e0 -7.852e-5
1 5 5 0.0000019407667236782136 0.0000019407667236782136 3.2610530e0 3.2611163e0 -1.943e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 3.7773898e0 3.7775120e0 -3.235e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 4.0546412e0 4.0546210e0 4.982e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 4.1613019e0 4.1613313e0 -7.072e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 4.1963326e0 4.1963081e0 5.836e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.2374306e0 4.2374955e0 -1.533e-5
7 5 5 0.006637328831200572 0.006637328831200572 4.0281254e0 4.0281433e0 -4.437e-6
8 5 5 0.02576301385940815 0.02576301385940815 3.0246906e0 3.0245962e0 3.123e-5
9 5 5 0.1 0.1 1.3753229e0 1.3753758e0 -3.844e-5
10 5 5 0.18 0.18 6.3178274e-1 6.3174437e-1 6.073e-5
11 5 5 0.26 0.26 3.3070458e-1 3.3069396e-1 3.211e-5
12 5 5 0.33999999999999997 0.33999999999999997 2.0033492e-1 2.0034140e-1 -3.233e-5
13 5 5 0.42000000000000004 0.42000000000000004 1.2173626e-1 1.2174600e-1 -8.004e-5
14 5 5 0.5 0.5 6.3538331e-2 6.3534689e-2 5.732e-5
15 5 5 0.58 0.58 2.6317776e-2 2.6314609e-2 1.204e-4
16 5 5 0.66 0.66 8.3569885e-3 8.3565226e-3 5.575e-5
17 5 5 0.74 0.74 1.8948271e-3 1.8952207e-3 -2.077e-4
18 5 5 0.82 0.82 2.7347304e-4 2.7423993e-4 -2.796e-3
19 5 5 0.9 0.9 1.9429825e-5 1.9786850e-5 -1.804e-2
The first column in diff is the value of the PineAPPL grid, the second the converted FK table FK_POSXGL.dat
and the third column the relative difference, using NNPDF40_nnlo_as_01180
. The agreement gets worse in the large x
region which we'd probably expect.
Here the remaining comparisons:
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 4.3673578e-1 4.3672388e-1 2.725e-5
1 5 5 0.0000019407667236782136 0.0000019407667236782136 3.5607646e-1 3.5605805e-1 5.171e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 2.8666402e-1 2.8665070e-1 4.646e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 2.2671085e-1 2.2670504e-1 2.564e-5
4 5 5 0.00011349672651536727 0.00011349672651536727 1.7434229e-1 1.7433803e-1 2.440e-5
5 5 5 0.00044054134013486355 0.00044054134013486355 1.2837917e-1 1.2837543e-1 2.910e-5
6 5 5 0.0017099759466766963 0.0017099759466766963 8.8852985e-2 8.8850052e-2 3.302e-5
7 5 5 0.006637328831200572 0.006637328831200572 5.6121632e-2 5.6120524e-2 1.975e-5
8 5 5 0.02576301385940815 0.02576301385940815 2.9225936e-2 2.9226634e-2 -2.387e-5
9 5 5 0.1 0.1 1.1516268e-2 1.1514661e-2 1.396e-4
10 5 5 0.18 0.18 9.9523920e-3 9.9519451e-3 4.490e-5
11 5 5 0.26 0.26 9.4488438e-3 9.4485852e-3 2.736e-5
12 5 5 0.33999999999999997 0.33999999999999997 8.7447941e-3 8.7446792e-3 1.314e-5
13 5 5 0.42000000000000004 0.42000000000000004 7.5868565e-3 7.5871588e-3 -3.984e-5
14 5 5 0.5 0.5 5.7241988e-3 5.7242193e-3 -3.588e-6
15 5 5 0.58 0.58 3.5527718e-3 3.5526951e-3 2.160e-5
16 5 5 0.66 0.66 1.7421918e-3 1.7420780e-3 6.531e-5
17 5 5 0.74 0.74 6.4508807e-4 6.4504430e-4 6.786e-5
18 5 5 0.82 0.82 1.5926157e-4 1.5922808e-4 2.103e-4
19 5 5 0.9 0.9 1.7412192e-5 1.7471112e-5 -3.372e-3
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 1.2393127e0 1.2393022e0 8.488e-6
1 5 5 0.0000019407667236782136 0.0000019407667236782136 1.0539690e0 1.0539518e0 1.629e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 8.9609498e-1 8.9608287e-1 1.351e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 7.6174301e-1 7.6173823e-1 6.276e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 6.4608981e-1 6.4608454e-1 8.155e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 5.4165201e-1 5.4164930e-1 4.995e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.4124240e-1 4.4123802e-1 9.929e-6
7 5 5 0.006637328831200572 0.006637328831200572 3.5069832e-1 3.5069820e-1 3.256e-7
8 5 5 0.02576301385940815 0.02576301385940815 2.7157938e-1 2.7158122e-1 -6.799e-6
9 5 5 0.1 0.1 1.5860744e-1 1.5860872e-1 -8.069e-6
10 5 5 0.18 0.18 8.5027084e-2 8.5031036e-2 -4.648e-5
11 5 5 0.26 0.26 3.5462191e-2 3.5460455e-2 4.897e-5
12 5 5 0.33999999999999997 0.33999999999999997 1.1731330e-2 1.1725191e-2 5.236e-4
13 5 5 0.42000000000000004 0.42000000000000004 5.8198823e-3 5.8206173e-3 -1.263e-4
14 5 5 0.5 0.5 5.2011944e-3 5.2014776e-3 -5.446e-5
15 5 5 0.58 0.58 3.8111076e-3 3.8110645e-3 1.131e-5
16 5 5 0.66 0.66 2.0527924e-3 2.0526132e-3 8.727e-5
17 5 5 0.74 0.74 8.3934080e-4 8.3920650e-4 1.600e-4
18 5 5 0.82 0.82 3.0259700e-4 3.0274406e-4 -4.857e-4
19 5 5 0.9 0.9 9.0243494e-5 9.0341577e-5 -1.086e-3
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 1.2425322e0 1.2425217e0 8.448e-6
1 5 5 0.0000019407667236782136 0.0000019407667236782136 1.0590022e0 1.0589850e0 1.622e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 9.0397489e-1 9.0396271e-1 1.348e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 7.7403022e-1 7.7402531e-1 6.346e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 6.6502087e-1 6.6501560e-1 7.918e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 5.7016156e-1 5.7015872e-1 4.980e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.8207315e-1 4.8206652e-1 1.376e-5
7 5 5 0.006637328831200572 0.006637328831200572 4.1447524e-1 4.1446647e-1 2.117e-5
8 5 5 0.02576301385940815 0.02576301385940815 4.1378753e-1 4.1378897e-1 -3.471e-6
9 5 5 0.1 0.1 4.2008945e-1 4.2008264e-1 1.622e-5
10 5 5 0.18 0.18 3.7408690e-1 3.7408743e-1 -1.398e-6
11 5 5 0.26 0.26 2.9921954e-1 2.9922180e-1 -7.566e-6
12 5 5 0.33999999999999997 0.33999999999999997 2.1352475e-1 2.1353165e-1 -3.236e-5
13 5 5 0.42000000000000004 0.42000000000000004 1.3254155e-1 1.3254355e-1 -1.509e-5
14 5 5 0.5 0.5 6.8517883e-2 6.8516359e-2 2.224e-5
15 5 5 0.58 0.58 2.8132518e-2 2.8130424e-2 7.446e-5
16 5 5 0.66 0.66 8.5566485e-3 8.5560789e-3 6.656e-5
17 5 5 0.74 0.74 1.7636416e-3 1.7639263e-3 -1.614e-4
18 5 5 0.82 0.82 3.4217978e-4 3.4317545e-4 -2.901e-3
19 5 5 0.9 0.9 9.6744253e-5 9.6974079e-5 -2.370e-3
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 1.2362209e0 1.2362104e0 8.511e-6
1 5 5 0.0000019407667236782136 0.0000019407667236782136 1.0498903e0 1.0498731e0 1.633e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 8.9058921e-1 8.9057709e-1 1.362e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 7.5398398e-1 7.5397920e-1 6.335e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 6.3437315e-1 6.3436723e-1 9.329e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 5.2235243e-1 5.2235025e-1 4.165e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.0612622e-1 4.0612185e-1 1.075e-5
7 5 5 0.006637328831200572 0.006637328831200572 2.8701093e-1 2.8700937e-1 5.446e-6
8 5 5 0.02576301385940815 0.02576301385940815 1.7478655e-1 1.7478955e-1 -1.716e-5
9 5 5 0.1 0.1 5.8673185e-2 5.8671461e-2 2.939e-5
10 5 5 0.18 0.18 2.3316737e-2 2.3316295e-2 1.895e-5
11 5 5 0.26 0.26 1.0190022e-2 1.0189184e-2 8.225e-5
12 5 5 0.33999999999999997 0.33999999999999997 6.1365527e-3 6.1356143e-3 1.529e-4
13 5 5 0.42000000000000004 0.42000000000000004 5.3380038e-3 5.3387678e-3 -1.431e-4
14 5 5 0.5 0.5 4.2646304e-3 4.2645310e-3 2.332e-5
15 5 5 0.58 0.58 2.8244790e-3 2.8245922e-3 -4.010e-5
16 5 5 0.66 0.66 1.5259960e-3 1.5259046e-3 5.985e-5
17 5 5 0.74 0.74 6.2885496e-4 6.2873913e-4 1.842e-4
18 5 5 0.82 0.82 2.2545476e-4 2.2555650e-4 -4.511e-4
19 5 5 0.9 0.9 6.8727037e-5 6.8834904e-5 -1.567e-3
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 1.2340403e0 1.2340297e0 8.524e-6
1 5 5 0.0000019407667236782136 0.0000019407667236782136 1.0467878e0 1.0467707e0 1.639e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 8.8626335e-1 8.8625117e-1 1.374e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 7.4817094e-1 7.4816605e-1 6.545e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 6.2709310e-1 6.2708738e-1 9.123e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 5.1450680e-1 5.1450411e-1 5.219e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.0140306e-1 4.0139914e-1 9.777e-6
7 5 5 0.006637328831200572 0.006637328831200572 2.8937228e-1 2.8937206e-1 7.662e-7
8 5 5 0.02576301385940815 0.02576301385940815 1.7954544e-1 1.7954709e-1 -9.194e-6
9 5 5 0.1 0.1 8.0760528e-2 8.0757036e-2 4.325e-5
10 5 5 0.18 0.18 5.0351752e-2 5.0354088e-2 -4.639e-5
11 5 5 0.26 0.26 2.8940135e-2 2.8940486e-2 -1.214e-5
12 5 5 0.33999999999999997 0.33999999999999997 1.5472660e-2 1.5468856e-2 2.459e-4
13 5 5 0.42000000000000004 0.42000000000000004 1.0822146e-2 1.0820789e-2 1.253e-4
14 5 5 0.5 0.5 9.9429408e-3 9.9437574e-3 -8.213e-5
15 5 5 0.58 0.58 7.4110113e-3 7.4110580e-3 -6.301e-6
16 5 5 0.66 0.66 3.7906701e-3 3.7902126e-3 1.207e-4
17 5 5 0.74 0.74 1.2808814e-3 1.2806010e-3 2.189e-4
18 5 5 0.82 0.82 2.9381353e-4 2.9396754e-4 -5.239e-4
19 5 5 0.9 0.9 6.5475460e-5 6.5806594e-5 -5.032e-3
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 1.2405356e0 1.2405250e0 8.497e-6
1 5 5 0.0000019407667236782136 0.0000019407667236782136 1.0556043e0 1.0555872e0 1.622e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 8.9828945e-1 8.9827734e-1 1.348e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 7.6465325e-1 7.6464849e-1 6.226e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 6.4976452e-1 6.4975907e-1 8.389e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 5.4556837e-1 5.4556603e-1 4.281e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.4285618e-1 4.4285260e-1 8.082e-6
7 5 5 0.006637328831200572 0.006637328831200572 3.4236858e-1 3.4236925e-1 -1.964e-6
8 5 5 0.02576301385940815 0.02576301385940815 2.3851112e-1 2.3851384e-1 -1.142e-5
9 5 5 0.1 0.1 1.0826740e-1 1.0826566e-1 1.614e-5
10 5 5 0.18 0.18 5.3312426e-2 5.3314476e-2 -3.846e-5
11 5 5 0.26 0.26 2.2300404e-2 2.2299125e-2 5.736e-5
12 5 5 0.33999999999999997 0.33999999999999997 7.6893571e-3 7.6870480e-3 3.004e-4
13 5 5 0.42000000000000004 0.42000000000000004 3.0482582e-3 3.0490887e-3 -2.724e-4
14 5 5 0.5 0.5 1.7784672e-3 1.7781696e-3 1.674e-4
15 5 5 0.58 0.58 1.6533254e-3 1.6531820e-3 8.671e-5
16 5 5 0.66 0.66 1.8898310e-3 1.8903552e-3 -2.773e-4
17 5 5 0.74 0.74 1.4804651e-3 1.4804722e-3 -4.798e-6
18 5 5 0.82 0.82 6.6492704e-4 6.6465074e-4 4.157e-4
19 5 5 0.9 0.9 1.4006028e-4 1.3981203e-4 1.776e-3
b x1 x2 diff
--+-+-+------------------------+------------------------+------------+------------+---------
0 5 5 0.0000005 0.0000005 1.2437703e0 1.2437597e0 8.482e-6
1 5 5 0.0000019407667236782136 0.0000019407667236782136 1.0606871e0 1.0606700e0 1.614e-5
2 5 5 0.000007533150951473337 0.000007533150951473337 9.0632551e-1 9.0631332e-1 1.346e-5
3 5 5 0.000029240177382128657 0.000029240177382128657 7.7742549e-1 7.7742053e-1 6.388e-6
4 5 5 0.00011349672651536727 0.00011349672651536727 6.7020423e-1 6.7019919e-1 7.524e-6
5 5 5 0.00044054134013486355 0.00044054134013486355 5.7884601e-1 5.7884243e-1 6.188e-6
6 5 5 0.0017099759466766963 0.0017099759466766963 4.9906310e-1 4.9905414e-1 1.795e-5
7 5 5 0.006637328831200572 0.006637328831200572 4.5337274e-1 4.5335954e-1 2.912e-5
8 5 5 0.02576301385940815 0.02576301385940815 5.0752126e-1 5.0751873e-1 4.982e-6
9 5 5 0.1 0.1 6.4872299e-1 6.4870323e-1 3.046e-5
10 5 5 0.18 0.18 6.9401118e-1 6.9400567e-1 7.935e-6
11 5 5 0.26 0.26 6.5053195e-1 6.5053436e-1 -3.705e-6
12 5 5 0.33999999999999997 0.33999999999999997 5.4212011e-1 5.4213499e-1 -2.744e-5
13 5 5 0.42000000000000004 0.42000000000000004 4.0319704e-1 4.0320090e-1 -9.568e-6
14 5 5 0.5 0.5 2.6733543e-1 2.6733388e-1 5.799e-6
15 5 5 0.58 0.58 1.5702804e-1 1.5702727e-1 4.902e-6
16 5 5 0.66 0.66 7.8611821e-2 7.8610399e-2 1.809e-5
17 5 5 0.74 0.74 3.0458779e-2 3.0456035e-2 9.008e-5
18 5 5 0.82 0.82 7.6309916e-3 7.6295353e-3 1.909e-4
19 5 5 0.9 0.9 8.0153125e-4 8.0348408e-4 -2.430e-3
Commit 7d0bf2f065dd64e4e66118ea57eaa8542bccc809 adds all positivity runcards that I can easily generate.
The only possible issue (@scarlehoff ?) left is that the x
at which the positivity of x * f(x)
is enforced, which are specified in positivity.yaml
, are identical to the x grids of the PineAPPL grids and different from the 50 grid x points we typically use. For convenience of the fit pineko should probably
Merging this PR will close #124.
Please have a look at this, that's the first Python code other than matplotlib scripts I've written in a while, every suggestion is welcome. At this point it's sort of a MVP, but a few things have to be done still: scale variation, metadata, ?. The x-grid must be specified in the runcard, let me know if that's a good idea.