Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Positivity #146

Merged
merged 15 commits into from
Sep 13, 2022
Merged

Positivity #146

merged 15 commits into from
Sep 13, 2022

Conversation

felixhekhorn
Copy link
Contributor

  • this is the yadism part of the DIS positivity implementation - it follows the previous apfel implementation, i.e. it is only active in the NC sector (as for CC the situation is more complicated due to CKM)
  • next in line is a accompanying PR in runcardsrunner
  • @scarlehoff or @cschwan: could you please remind me how to get the actual settings? (from the old FK table?) i.e. we need F2up(x=?,Q2=?)

@felixhekhorn felixhekhorn added enhancement New feature or request physics physics features labels Jul 20, 2022
@codecov
Copy link

codecov bot commented Jul 20, 2022

Codecov Report

Merging #146 (50871d0) into develop (6f12a31) will increase coverage by 0.08%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop     #146      +/-   ##
===========================================
+ Coverage    68.74%   68.82%   +0.08%     
===========================================
  Files           82       82              
  Lines         3996     4007      +11     
===========================================
+ Hits          2747     2758      +11     
  Misses        1249     1249              
Flag Coverage Δ
unittests 68.82% <100.00%> (+0.08%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...yadism/coefficient_functions/coupling_constants.py 100.00% <100.00%> (ø)
src/yadism/coefficient_functions/fonll/kernels.py 9.37% <100.00%> (+0.95%) ⬆️
src/yadism/coefficient_functions/heavy/kernels.py 16.66% <100.00%> (+2.03%) ⬆️
.../yadism/coefficient_functions/intrinsic/kernels.py 16.00% <100.00%> (+3.50%) ⬆️
src/yadism/coefficient_functions/kernels.py 15.00% <100.00%> (ø)
src/yadism/coefficient_functions/light/kernels.py 13.88% <100.00%> (+2.46%) ⬆️

@alecandido
Copy link
Member

alecandido commented Jul 20, 2022

  • @scarlehoff or @cschwan: could you please remind me how to get the actual settings? (from the old FK table?) i.e. we need F2up(x=?,Q2=?)

This part should be implemented as a suitable runcard, not in yadism

Copy link
Contributor

@andreab1997 andreab1997 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look and everything seems good to me. However I am not that much familiar with yadism so I cannot really say that I have understood all the changes you have done.

@felixhekhorn
Copy link
Contributor Author

  • @scarlehoff or @cschwan: could you please remind me how to get the actual settings? (from the old FK table?) i.e. we need F2up(x=?,Q2=?)

This part should be implemented as a suitable runcard, not in yadism

actually, yes and no: of course everything will eventually end up in runcardsrunner (as said): NNPDF/pinecards#143 - but it will be just a plain copy (as for the other DIS experiments); first I'd like to take advantage of the data package here which allows me an easy benchmark

@felixhekhorn
Copy link
Contributor Author

@enocera thanks for your info! I hope I implemented the python equivalent here - however when running a simple, LO benchmark against apfel it is complaining " Invalid value of x = 4.9999999999999998E-007" (full output below) ... do you know if they (=apfelcomb) hacked apfel in some way to run it (i.e. extend it's default grids)? in any case I try to benchmark against the old FK table ...

WARNING: ZM-VFNS is a VFN scheme
        ... setting VFNS PDF evolution

Welcome to
/// //// //// ///_/ _/
_/ / / / / / /
//
/
/ //
/
/ //
/ //
/ _/
_/ _/ _/ _/ _/ _/
/ / / / //// ////
_____v3.0.5 A PDF Evolution Library, arXiv:1310.1394
Authors: V. Bertone, S. Carrazza, J. Rojo

Report of the evolution parameters:

QCD evolution
Space-like evolution (PDFs)
Unpolarized evolution
Evolution scheme: VFNS at N0LO
Solution of the DGLAP equation: 'truncated' with maximum 5 active flavours

  • value of the truncation parameter epsilon = 1.000E-02
    Solution of the coupling equations: 'expanded' with maximum 5 active flavours
    Coupling reference value:
  • AlphaQCD( 91.2000 GeV) = 0.118000
    Pole heavy quark masses:
  • Mc = 1.5100 GeV
  • Mb = 4.9200 GeV
  • Mt = 172.5000 GeV
    The matching thresholds coincide with the physical masses
    muR / muF = 1.0000

Allowed evolution range [ 1.0000 : 10000.0000 ] GeV
The internal subgrids will be locked
Fast evolution enabled

Initialization of the evolution completed in 0.140 s

Report of the electroweak parameters:

Mass of the Z = 91.188 GeV
Mass of the W = 80.398 GeV
Mass of the proton = 0.9380 GeV
sin^2(thetaW) = 0.2313
GFermi = 1.16638E-05
| 0.9743 0.2253 0.0035 |
CKM = | 0.2252 0.9735 0.0410 |
| 0.0086 0.0403 0.9992 |
Z propagator correction = 0.00000

Report of the DIS parameters:

Computation in the ZM-VFNS mass scheme
Electromagnetic (EM) process
Scattering electron - proton
Selected Charge: upW
muR / Q = 1.0000
muF / Q = 1.0000
(No scale variation in the evolution)
Target Mass corrections disabled
Intrinsic charm enabled

Initialization of the DIS module completed in 0.018 s

In F2light.f:
Invalid value of x = 4.9999999999999998E-007

@enocera
Copy link

enocera commented Jul 20, 2022

@felixhekhorn This is strange. If I run apfelcomb it runs just fine. And as far as I know, apfel has not been hacked for the purpose of positivity observables. Have you tried to sample the x grid, instead from x=5e-7, from 5.000001e-7?

@felixhekhorn
Copy link
Contributor Author

@enocera yes I tried, and this does not work either - in fact I believe the minimum x-grid value in apfel is 1e-5 as defined here: https://github.com/scarrazza/apfel/blob/4426f689a95fbde94012083dd55a9af0edcc5928/src/Evolution/initParameters.f#L89 and indeed this works

PS: since we're speaking of it and you might be interested in the future: our default x_min is 2e-7 as defined by the PineAPPL paper https://github.com/N3PDF/yadism/blob/ecc16f965504435423e44868790cf5d154e0d7b2/extras/data/machinery/generate/utils.py#L12

@felixhekhorn
Copy link
Contributor Author

felixhekhorn commented Jul 21, 2022

alright, there are strange things happening ... someone has an idea? @alecandido @cschwan @scarlehoff @enocera

the summary is:

  • I'm fine with APFEL
  • APFEL produced the old FK table
  • I'm not fine with the old FK table

check against apfel

if I fix the x_min problem, by either putting the cut temporarily to 5e-5 or by forcing APFEL to use my grid (which has support in that region) I'm getting something reasonable:

────────── 
F2_light  
────────── 
         x   Q2    yadism  yadism_error     apfel  percent_error
0   0.000050  5.0  0.442902  5.312145e-08  0.442726       0.039748
1   0.000116  5.0  0.403632  4.669570e-08  0.403492       0.034836
2   0.000271  5.0  0.369041  3.252406e-08  0.368935       0.028554
3   0.000630  5.0  0.339594  8.300852e-09  0.339521       0.021258
4   0.001466  5.0  0.316099  1.823523e-08  0.316054       0.014323
5   0.003411  5.0  0.299781  7.023960e-09  0.299749       0.010525
6   0.007937  5.0  0.292316  2.314373e-09  0.292278       0.012975
7   0.018469  5.0  0.295652  3.972416e-09  0.295585       0.022687
8   0.042975  5.0  0.310746  2.912102e-09  0.310624       0.039088
9   0.100000  5.0  0.331293  4.252015e-09  0.331131       0.048840
10  0.180000  5.0  0.330960  1.028598e-08  0.330671       0.087284
11  0.260000  5.0  0.307749  2.145948e-09  0.307232       0.168023
12  0.340000  5.0  0.269997  6.825300e-09  0.269240       0.280919
13  0.420000  5.0  0.224804  3.647180e-09  0.223667       0.508251
14  0.500000  5.0  0.177497  2.693862e-09  0.176350       0.650124
15  0.580000  5.0  0.132795  3.235232e-09  0.131753       0.790963
16  0.660000  5.0  0.093696  2.075620e-09  0.092833       0.929507
17  0.740000  5.0  0.061771  1.123380e-09  0.061122       1.062400
18  0.820000  5.0  0.037425  6.133458e-10  0.036976       1.214015
19  0.900000  5.0  0.020215  3.444571e-10  0.019936       1.400430
  • this uses theory 200 and the Les Houches Toy PDF
  • so something must be working
  • the deviation in the large-x region I'm willing to accept because, e.g. we do not implement the same TMC procedure as APFEL and of course TMC is active as I said we're using theory 200

the old FK table

when I look into the NNPDF FK table I can see problems:

  • @scarlehoff do you confirm, you send me the theory 200 one?
  • it is using a not-so-old version of APFEL:
_VersionInfo________________________________________________
*APFEL: 3.0.4
*APPLrepo: 8df7364dff076c871ff6ba9325c45032a10a14cc
*GenTime: Wed Dec 30 12:43:11 2020
*libnnpdf: 1.2.0b5
  • however, the xGrid starts at 4.9499999999997663e-07 - so not the default one (or the one I believe to be default); moreover this suggest that indeed the lowest bin does contain 5e-7 as it should (so buildmaster tells the correct story - question is how to get there)
  • also, by inspecting the theory card, I can see it has PTO: 2, so theory 200, yet it also has TMC: 0 - which is just crazy because this is not theory 200
  • it also has NDATA: 20

comparing new against old inside vp

  • together with @scarlehoff we tried to compare the old against the new ... however, when doing so vp cuts some points away from the FK table (due to "cuts") which I don't understand (and I believe also @scarlehoff wasn't convinced) - so I currently can't do the comparison there

comparing new against old with pineappl

  • using pineappl import I can convert the old FK table and if I do the comparison here, however, I get quite a discrepancy
$ pineappl diff NNPDF_POS_F2U_40-20220721125140/NNPDF_POS_F2U_40.pineappl.lz4 FK_POSF2U.pineappl.lz4 NNPDF40_nnlo_as_01180 --ignore-orders --ignore-lumis --ignore-bin-limits
LHAPDF 6.4.0 loading /home/felix/local/share/LHAPDF/NNPDF40_nnlo_as_01180/NNPDF40_nnlo_as_01180_0000.dat
NNPDF40_nnlo_as_01180 PDF set, member #0, version 1; LHAPDF ID = 331100
b  x1                         x2                                        diff               
--+-+-+------------------------+------------------------+------------+------------+--------
 0 5 5                0.0000005                0.0000005  1.6881982e0  1.1268024e0 4.982e-1
 1 5 5 0.0000019407667236782136 0.0000019407667236782136  1.4156454e0 9.4580687e-1 4.968e-1
 2 5 5  0.000007533150951473337  0.000007533150951473337  1.1833248e0 7.9170818e-1 4.946e-1
 3 5 5  0.000029240177382128657  0.000029240177382128657 9.8711750e-1 6.6186385e-1 4.914e-1
 4 5 5   0.00011349672651536727   0.00011349672651536727 8.2266779e-1 5.5392592e-1 4.852e-1
 5 5 5   0.00044054134013486355   0.00044054134013486355 6.8417510e-1 4.6437428e-1 4.733e-1
 6 5 5    0.0017099759466766963    0.0017099759466766963 5.6277330e-1 3.8776300e-1 4.513e-1
 7 5 5     0.006637328831200572     0.006637328831200572 4.6188521e-1 3.2780191e-1 4.090e-1
 8 5 5      0.02576301385940815      0.02576301385940815 4.0735276e-1 3.0528532e-1 3.343e-1
 9 5 5                      0.1                      0.1 3.7176559e-1 3.0173775e-1 2.321e-1
10 5 5                     0.18                     0.18 3.5161177e-1 2.9818749e-1 1.792e-1
11 5 5                     0.26                     0.26 3.1473417e-1 2.7757600e-1 1.339e-1
12 5 5      0.33999999999999997      0.33999999999999997 2.6319517e-1 2.4051524e-1 9.430e-2
13 5 5      0.42000000000000004      0.42000000000000004 2.0646899e-1 1.9362557e-1 6.633e-2
14 5 5                      0.5                      0.5 1.5063930e-1 1.4153918e-1 6.429e-2
15 5 5                     0.58                     0.58 1.0198537e-1 9.3400529e-2 9.191e-2
16 5 5                     0.66                     0.66 6.4262863e-2 5.4767371e-2 1.734e-1
17 5 5                     0.74                     0.74 3.7223216e-2 2.6160118e-2 4.229e-1
18 5 5                     0.82                     0.82 1.9104176e-2 8.4611946e-3  1.258e0
19 5 5                      0.9                      0.9 8.2198888e-3 1.2610145e-3  5.518e0
  • (Note that I'm comparing a FK table against a grid - but that is fine since I'm using a PDF which encodes the missing evolution)

@alecandido
Copy link
Member

  • APFEL produced the old FK table

Then I might doubt this statement: the version of APFEL used to produce old FkTables is not the same as yours. In the meanwhile a few things have been changed... (in principle not so relevant)

  • I'm fine with APFEL

On the other side, APFEL is Evolution + DIS. You agree with DIS, so the problem might still be inside evolution (at the level of FkTables).

@enocera
Copy link

enocera commented Jul 21, 2022

@felixhekhorn (cc @scarlehoff @alecandido). Let me make some remarks.

  1. The version of apfel (3.0.4) used to generate the FK tables should be the same for all FK tables. This was the latest available version of APFEL when FK tables were generated for NNPDF4.0 (January 2021).
  2. TMCs are disabled by default when computing DIS positivity observables, irrespective of the theory. This is done at the level of apfelcomb, see https://github.com/NNPDF/apfelcomb/blob/f49871435792bff1e269d524c3e6861aa6dd3e28/src/core/fk_qcd.cc#L150. The reason for this can be discussed at one of our Friday's phone calls (or I guess that an answer can be found by digging into the old NNPDF papers).
  3. The default APFEL x grid is NOT used for any FK table. An external x grid is defined by apfelcomb, which is passed to APFEL (see https://github.com/NNPDF/apfelcomb/blob/f49871435792bff1e269d524c3e6861aa6dd3e28/src/core/fk_qcd.cc#L244, with the definition of xg given here https://github.com/NNPDF/apfelcomb/blob/f49871435792bff1e269d524c3e6861aa6dd3e28/src/core/fk_qcd.cc#L228). This explains why xmin=5e-7, as defined in the commondata, is passed to APFEL, why APFEL does not complain, and why xmin in the FK table is indeed 5e-7.
  4. fNData=20 should be correct - this is consistent with buildmaster, as we discussed yesterday.
  5. As for cuts, I guess that vp (DIS) cuts apply to all DIS data sets (and FK tables), including positivity data sets (and FK tables). I don't see any problem with this.

@felixhekhorn
Copy link
Contributor Author

Since the comparison seems alright - I'm ready to merge; @alecandido whenever you have time, please review and we merge

  • apart from the positivity stuff this PR also updates the pylint config

PS: in the end the non-matching was just due to not using the correct version inside pinefarm 🙈 thanks @scarlehoff for making me realize

Copy link
Member

@alecandido alecandido left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First batch, I still have to check most of the part in the yadism package itself.
Mostly trivial stuffs.

benchmarks/runners/apfel_.py Show resolved Hide resolved
benchmarks/runners/apfel_.py Show resolved Hide resolved
extras/data/POS_F2C/c.yaml Show resolved Hide resolved
extras/data/POS_F2D/d.yaml Outdated Show resolved Hide resolved
extras/data/POS_F2S/s.yaml Outdated Show resolved Hide resolved
extras/data/POS_F2D/metadata.yaml Show resolved Hide resolved
extras/data/POS_F2U/u.yaml Outdated Show resolved Hide resolved
extras/data/POS_FLL/metadata.yaml Outdated Show resolved Hide resolved
extras/data/Makefile Outdated Show resolved Hide resolved
@alecandido
Copy link
Member

Overall, there are only minor corrections and a few clarifications to be provided.
If you are able to take care of this, it should take you ~1h (generous estimate, but in any case no more than 2), then I'm happy to merge. And consequently regenerate data, and merge the twin runcards PR.

Copy link
Member

@alecandido alecandido left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Proposed a tiny improvement. But don't mind about this right here: even if you'd do it immediately, first merge, then fix in develop.

@felixhekhorn felixhekhorn merged commit 664e05b into develop Sep 13, 2022
@felixhekhorn felixhekhorn deleted the feature/positivity branch September 13, 2022 14:19
@alecandido
Copy link
Member

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request physics physics features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants