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

Strong coupling constants are wrongly calculated #89

Closed
cschwan opened this issue Apr 24, 2023 · 7 comments
Closed

Strong coupling constants are wrongly calculated #89

cschwan opened this issue Apr 24, 2023 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@cschwan
Copy link
Contributor

cschwan commented Apr 24, 2023

This was originally reported here: NNPDF/pineappl#226, but I'm quite confident that this is a bug in Pineko, specifically these lines:

pineko/src/pineko/evolve.py

Lines 200 to 207 in f8c3261

alphas_values = [
4.0
* np.pi
* sc.a_s(
xir * xir * muf2 / xif / xif,
)
for muf2 in muf2_grid
]

which evaluate the strong coupling constant that do not correspond the renormalization scales given here:

xir * xir * mur2_grid,

I believe the patch is to change these lines as follows, with which I get the correct evolution (tested with CMS_TTB_5TEV_TOT):

@@ -201,9 +201,9 @@ def evolve_grid(
         4.0
         * np.pi
         * sc.a_s(
-            xir * xir * muf2 / xif / xif,
+            xir * xir * mur2,
         )
-        for muf2 in muf2_grid
+        for mur2 in mur2_grid
     ]
     # We need to use ekompatibility in order to pass a dictionary to pineappl
     fktable = grid.evolve(
@cschwan cschwan added the bug Something isn't working label Apr 24, 2023
@cschwan cschwan changed the title Strong coupling constants are treated incorrectly Strong coupling constants are wrongly calculated Apr 24, 2023
@alecandido
Copy link
Member

@andreab1997 can you try applying the patch above and recomputing, please?

@andreab1997
Copy link
Contributor

andreab1997 commented Apr 25, 2023

Yes I can try but I don't understand how this can be a bug. @cschwan did you understand what is the problem?

@andreab1997
Copy link
Contributor

Moreover, I got the correct predictions just removing the grid optimize which is completely unrelated to this.

@andreab1997
Copy link
Contributor

So it seems that you were actually correct, applying that patch solved the problem. This is the new comparison
comparison_424.txt
As you can see there is only one problem at the beginning but I believe my eko to be bugged. Let me try to recompute it but I am pretty sure. For the rest everything seems to be fine.

@andreab1997
Copy link
Contributor

No I was wrong, it seems that the ATLASDY2D8TEV is a real bug.

@cschwan
Copy link
Contributor Author

cschwan commented Apr 25, 2023

I found the bug by printing the OperatorInfo struct passed to Grid::evolve on stderr for 1) pineappl evolve and 2) Pineko. For CMS_TTB_5TEV_TOT I find in both cases that

ren1: [
    5442.305429193529,
    7434.731381687921,
    10243.85467001917,
    14238.990475802799,
    19971.806922234402,
    28273.883344269376,
    40410.48232844362,
    58325.25318921733,
    85033.47534094655,
    125260.40013230646,
    186488.2133214792,
    280691.4902174795,
    427245.3808062111,
    657853.7431299294,
    1024996.5523865514,
    1616581.2577807596,
    2581663.421106388
]

So far so good. pineappl evolve calculates the strong coupling constant as:

alphas: [
    0.12190944075548889,
    0.11900892802232749,
    0.11617243718593613,
    0.11339821043907347,
    0.11068598682266634,
    0.1080343743829495,
    0.10544130425131869,
    0.10290650940538232,
    0.1004289992066687,
    0.09800656568331764,
    0.09563886186878709,
    0.09332518460075083,
    0.09106334734236118,
    0.08885286965181682,
    0.08669325984311221,
    0.08458246767160318,
    0.0825198335061508
]

As expected, this vector has the same size as ren1. But this isn't the case for Pineko:

alphas: [
    0.17812293619077232,
    0.17401253126774863,
    0.16998863674128645,
    0.16604972179241928,
    0.16219427022194413,
    0.15842078120174546,
    0.15472776993464313,
    0.15111376822948233,
    0.1475773249979303,
    0.14411700667916258,
    0.14073139759833034,
    0.13741910026440088,
    0.13417873561265617,
    0.13100894319682557,
    0.12790838133552054,
    0.12487572721733475,
    0.12190967696867401,
    0.11900894568808806,
    0.11617226745059381,
    0.11339839528520783,
    0.11068610112864455,
    0.10803417575788739,
    0.10544142870410592,
    0.10290668815016772,
    0.10042880081378519,
    0.09800663181814082,
    0.09563906455165323,
    0.09332500051837454,
    0.09106335918035456,
    0.08885307779316161,
    0.08669311123561792,
    0.08458243183468485,
    0.08252002918632481,
    0.08050490997306427,
    0.07853609777889299,
    0.07661263290205221,
    0.07473357216619243,
    0.07289798873031418,
    0.0711049718978489,
    0.0693536269251842
]

This can't be right, because the length of this vector doesn't match the length of ren1. Looking at the code above this makes sense: you calculate alphas at xir * xir * muf2 / xif / xif for whatever value muf2 is contained in muf2_grid, but as the corresponding scales you pass xir * xir * mur2_grid. So there's clearly a mismatch.

@cschwan
Copy link
Contributor Author

cschwan commented Apr 25, 2023

For ATLASDY2D8TEV-aMCfast_obs_0 I get with pineappl evolve:

$ pineappl write --optimize ATLASDY2D8TEV-aMCfast_obs_0.pineappl.lz4 ATLASDY2D8TEV-aMCfast_obs_0-opt.pineappl.lz4
$ pineappl evolve ATLASDY2D8TEV-aMCfast_obs_0.pineappl.lz4 ATLASDY2D8TEV-aMCfast_obs_0.tar /tmp/deleteme.pineappl.lz4 NNPDF40_nnlo_as_01180
b      Grid       FkTable      rel. diff
--+------------+------------+-------------
0   2.7400418e0  2.7371347e0 -1.0609672e-3
1   2.7347464e0  2.7319391e0 -1.0265585e-3
2   2.7298912e0  2.7269958e0 -1.0606106e-3
3   2.7085291e0  2.7056548e0 -1.0612065e-3
4   2.6923000e0  2.6897803e0 -9.3589734e-4
5   2.6496577e0  2.6472263e0 -9.1763037e-4
6   2.5742308e0  2.5722173e0 -7.8215776e-4
7   2.3675544e0  2.3656406e0 -8.0836710e-4
8   1.9878036e0  1.9862178e0 -7.9778839e-4
9   1.5272002e0  1.5261000e0 -7.2043371e-4
10  1.0084506e0  1.0077076e0 -7.3677997e-4
11 4.8781048e-1 4.8746251e-1 -7.1332031e-4

This looks OK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants