DIS: structure functions in low Q2 regime seems wrong

[felixhekhorn]

• We believe that APFEL is doing something wrong in the low Q2 regime, i.e., below some quark threshold
• in FFNS3 we get a perfect agreement (or as perfect as we can get, when disabling the interpolation)
• we believe that in FFNS4 there are no relevant thresholds as masses are either 0 or infinite; however APFEL is sensitive to the quark masses: here mc=2,mb=4
• the worring fact is that APFEL is not a continuous function near threshold (but Yadism is) - we thus believe APFEL is wrong
• also the ZM-VFNS configuration has the same kind of defect

Below we attach some logs that we created; we also attached the theory input for the first log - in all subsequent logs we only change the indicated FNS

theory 97

{'ID': 22,
 'PTO': 0,
 'FNS': 'FFNS',
 'DAMP': 0,
 'IC': 0,
 'ModEv': 'EXA',
 'XIR': 1.0,
 'XIF': 1.0,
 'NfFF': 3,
 'MaxNfAs': 6,
 'MaxNfPdf': 6,
 'Q0': 1,
 'alphas': 0.11800000000000001,
 'Qref': 91.2,
 'QED': 0,
 'alphaqed': 0.007496251999999999,
 'Qedref': 1.777,
 'SxRes': 0,
 'SxOrd': 'LL',
 'HQ': 'POLE',
 'mc': 2,
 'Qmc': 2,
 'kcThr': 1.0,
 'mb': 4,
 'Qmb': 4,
 'kbThr': 1.0,
 'mt': 173.07,
 'Qmt': 173.07,
 'ktThr': 1.0,
 'CKM': '0.97428 0.22530 0.003470 0.22520 0.97345 0.041000 0.00862 0.04030 0.999152',
 'MZ': 91.1876,
 'MW': 80.398,
 'GF': 1.1663787e-05,
 'SIN2TW': 0.23126,
 'TMC': 0,
 'MP': 0.938,
 'Comments': 'LO baseline for small-x res',
 'global_nx': 0,
 'EScaleVar': 1,
 '_modify_time': '2020-05-28 16:55:02.150509'}

FFNS3

F2total with theory=97 using CT14llo_NF6
           x          Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.000100   90.000000  2.243980  2.243980           0.0   -0.000004
1   0.000317   90.000000  1.639572  1.639572           0.0   -0.000004
2   0.001007   90.000000  1.182349  1.182349           0.0   -0.000004
3   0.003195   90.000000  0.846563  0.846563           0.0   -0.000004
4   0.010138   90.000000  0.623498  0.623498           0.0   -0.000004
5   0.032169   90.000000  0.483802  0.483802           0.0   -0.000004
6   0.102077   90.000000  0.370392  0.370392           0.0   -0.000004
7   0.304545   90.000000  0.225637  0.225637           0.0   -0.000003
8   0.536364   90.000000  0.072848  0.072848           0.0   -0.000003
9   0.768182   90.000000  0.007164  0.007164           0.0   -0.000003
10  1.000000   90.000000  0.000000  0.000000           0.0         NaN
11  0.845455   90.000000  0.001729  0.001729           0.0   -0.000003
12  0.922727   90.000000  0.000148  0.000148           0.0   -0.000003
13  1.000000   90.000000  0.000000  0.000000           0.0         NaN
14  0.010000    2.000000  0.420156  0.420175           0.0    0.004658
15  0.010000    3.088904  0.446229  0.446251           0.0    0.004783
16  0.010000    4.770665  0.472257  0.472281           0.0    0.005041
17  0.010000    7.368063  0.497732  0.497759           0.0    0.005401
18  0.010000   11.379620  0.522376  0.522406           0.0    0.005827
19  0.010000   17.575279  0.546045  0.546080           0.0    0.006287
20  0.010000   27.144176  0.568668  0.568707           0.0    0.006788
21  0.010000   41.922880  0.590220  0.590263           0.0    0.007298
22  0.010000   64.747880  0.610707  0.610755           0.0    0.007827
23  0.010000  100.000000  0.630162  0.630215           0.0    0.008352

FFNS4

F2total with theory=99 using CT14llo_NF6
           x          Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.000100   90.000000  3.231555  3.231554           0.0   -0.000004
1   0.000317   90.000000  2.317068  2.317068           0.0   -0.000004
2   0.001007   90.000000  1.627903  1.627903           0.0   -0.000004
3   0.003195   90.000000  1.119541  1.119541           0.0   -0.000004
4   0.010138   90.000000  0.771808  0.771808           0.0   -0.000004
5   0.032169   90.000000  0.550866  0.550866           0.0   -0.000004
6   0.102077   90.000000  0.394615  0.394615           0.0   -0.000004
7   0.304545   90.000000  0.230012  0.230012           0.0   -0.000004
8   0.536364   90.000000  0.073214  0.073214           0.0   -0.000004
9   0.768182   90.000000  0.007169  0.007169           0.0   -0.000004
10  1.000000   90.000000  0.000000  0.000000           0.0         NaN
11  0.845455   90.000000  0.001729  0.001729           0.0   -0.000004
12  0.922727   90.000000  0.000148  0.000148           0.0   -0.000004
13  1.000000   90.000000  0.000000  0.000000           0.0         NaN
14  0.010000    2.000000  0.493705  0.426851           0.0  -13.541340
15  0.010000    3.088904  0.553139  0.471357           0.0  -14.785185
16  0.010000    4.770665  0.515436  0.515463           0.0    0.005241
17  0.010000    7.368063  0.558580  0.558612           0.0    0.005756
18  0.010000   11.379620  0.600308  0.600346           0.0    0.006350
19  0.010000   17.575279  0.640385  0.640430           0.0    0.006980
20  0.010000   27.144176  0.678697  0.678749           0.0    0.007633
21  0.010000   41.922880  0.715204  0.715264           0.0    0.008301
22  0.010000   64.747880  0.749925  0.749992           0.0    0.008971
23  0.010000  100.000000  0.782909  0.782985           0.0    0.009625

FFNS5

F2total with theory=101 using CT14llo_NF6
           x          Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.000100   90.000000  3.349632  3.349632           0.0   -0.000004
1   0.000317   90.000000  2.392680  2.392680           0.0   -0.000004
2   0.001007   90.000000  1.673884  1.673884           0.0   -0.000004
3   0.003195   90.000000  1.145424  1.145424           0.0   -0.000004
4   0.010138   90.000000  0.784716  0.784716           0.0   -0.000004
5   0.032169   90.000000  0.556219  0.556219           0.0   -0.000004
6   0.102077   90.000000  0.396307  0.396307           0.0   -0.000004
7   0.304545   90.000000  0.230248  0.230248           0.0   -0.000004
8   0.536364   90.000000  0.073230  0.073230           0.0   -0.000004
9   0.768182   90.000000  0.007169  0.007169           0.0   -0.000004
10  1.000000   90.000000  0.000000  0.000000           0.0         NaN
11  0.845455   90.000000  0.001729  0.001729           0.0   -0.000004
12  0.922727   90.000000  0.000148  0.000148           0.0   -0.000004
13  1.000000   90.000000  0.000000  0.000000           0.0         NaN
14  0.010000    2.000000  0.519120  0.426851           0.0  -17.774098
15  0.010000    3.088904  0.580841  0.471357           0.0  -18.849231
16  0.010000    4.770665  0.526678  0.515463           0.0   -2.129342
17  0.010000    7.368063  0.570659  0.558612           0.0   -2.110929
18  0.010000   11.379620  0.613196  0.600346           0.0   -2.095608
19  0.010000   17.575279  0.640385  0.640430           0.0    0.006980
20  0.010000   27.144176  0.680323  0.680375           0.0    0.007657
21  0.010000   41.922880  0.721307  0.721368           0.0    0.008385
22  0.010000   64.747880  0.760046  0.760115           0.0    0.009106
23  0.010000  100.000000  0.796843  0.796921           0.0    0.009806

ZM-VFNS

F2total with theory=102 using CT14llo_NF6
           x          Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.000100   90.000000  3.349632  3.349632           0.0   -0.000004
1   0.000317   90.000000  2.392680  2.392680           0.0   -0.000004
2   0.001007   90.000000  1.673884  1.673884           0.0   -0.000004
3   0.003195   90.000000  1.145424  1.145424           0.0   -0.000004
4   0.010138   90.000000  0.784716  0.784716           0.0   -0.000004
5   0.032169   90.000000  0.556219  0.556219           0.0   -0.000004
6   0.102077   90.000000  0.396307  0.396307           0.0   -0.000004
7   0.304545   90.000000  0.230248  0.230248           0.0   -0.000004
8   0.536364   90.000000  0.073230  0.073230           0.0   -0.000004
9   0.768182   90.000000  0.007169  0.007169           0.0   -0.000004
10  1.000000   90.000000  0.000000  0.000000           0.0         NaN
11  0.845455   90.000000  0.001729  0.001729           0.0   -0.000004
12  0.922727   90.000000  0.000148  0.000148           0.0   -0.000004
13  1.000000   90.000000  0.000000  0.000000           0.0         NaN
14  0.010000    2.000000  0.423493  0.420175           0.0   -0.783537
15  0.010000    3.088904  0.458781  0.446251           0.0   -2.731341
16  0.010000    4.770665  0.515436  0.515463           0.0    0.005241
17  0.010000    7.368063  0.558580  0.558612           0.0    0.005756
18  0.010000   11.379620  0.600308  0.600346           0.0    0.006350
19  0.010000   17.575279  0.640385  0.640430           0.0    0.006980
20  0.010000   27.144176  0.680323  0.680375           0.0    0.007657
21  0.010000   41.922880  0.721307  0.721368           0.0    0.008385
22  0.010000   64.747880  0.760046  0.760115           0.0    0.009106
23  0.010000  100.000000  0.796843  0.796921           0.0    0.009806

[juanrojochacon]

@felixhekhorn have you tried the comparison only for the light structure function? Clearly the differences are related to the heavy quark structure function. I seem to recall that very close to the heavy quark threshold the interpolation could sometimes fail unless its settings were adjusted.

Also, what is exactly F2 at LO is a matter of discussion. One could define it as saying that all O(alpha_S) corrections to the SF are dumped, so F2c = F2_ZMVFN for all values of Q. But maybe in your code this is defined in a different way?

If you can redo this comparison in FFNS4 but only for the light part of the SFs I think we will learn something.

[felixhekhorn]

Unfortunately also the light structure functions are affected

FFNS3

F2light with theory=97 using CT14llo_NF6
       x         Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.01   2.000000  0.420156  0.420175           0.0    0.004658
1   0.01   3.058824  0.445640  0.445661           0.0    0.004779
2   0.01   4.117647  0.463487  0.463510           0.0    0.004940
3   0.01   5.176471  0.477093  0.477118           0.0    0.005103
4   0.01   6.235294  0.488035  0.488060           0.0    0.005257
5   0.01   7.294118  0.497149  0.497176           0.0    0.005392
6   0.01   8.352941  0.504940  0.504968           0.0    0.005515
7   0.01   9.411765  0.511725  0.511754           0.0    0.005632
8   0.01  10.470588  0.517729  0.517759           0.0    0.005741
9   0.01  11.529412  0.523102  0.523133           0.0    0.005840
10  0.01  12.588235  0.527961  0.527993           0.0    0.005931
11  0.01  13.647059  0.532394  0.532426           0.0    0.006016
12  0.01  14.705882  0.536465  0.536497           0.0    0.006095
13  0.01  15.764706  0.540223  0.540256           0.0    0.006170
14  0.01  16.823529  0.543711  0.543745           0.0    0.006239
15  0.01  17.882353  0.546967  0.547002           0.0    0.006307
16  0.01  18.941176  0.550017  0.550052           0.0    0.006371
17  0.01  20.000000  0.552884  0.552920           0.0    0.006432

FFNS4

F2light with theory=99 using CT14llo_NF6
       x         Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.01   2.000000  0.423493  0.420175           0.0   -0.783537
1   0.01   3.058824  0.457987  0.445661           0.0   -2.691352
2   0.01   4.117647  0.463487  0.463510           0.0    0.004940
3   0.01   5.176471  0.477093  0.477118           0.0    0.005103
4   0.01   6.235294  0.488035  0.488060           0.0    0.005257
5   0.01   7.294118  0.497149  0.497176           0.0    0.005392
6   0.01   8.352941  0.504940  0.504968           0.0    0.005515
7   0.01   9.411765  0.511725  0.511754           0.0    0.005632
8   0.01  10.470588  0.517729  0.517759           0.0    0.005741
9   0.01  11.529412  0.523102  0.523133           0.0    0.005840
10  0.01  12.588235  0.527961  0.527993           0.0    0.005931
11  0.01  13.647059  0.532394  0.532426           0.0    0.006016
12  0.01  14.705882  0.536465  0.536497           0.0    0.006095
13  0.01  15.764706  0.540223  0.540256           0.0    0.006170
14  0.01  16.823529  0.543711  0.543745           0.0    0.006239
15  0.01  17.882353  0.546967  0.547002           0.0    0.006306
16  0.01  18.941176  0.550017  0.550052           0.0    0.006370
17  0.01  20.000000  0.552884  0.552920           0.0    0.006431

FFNS5

F2light with theory=101 using CT14llo_NF6
       x         Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.01   2.000000  0.423493  0.420175           0.0   -0.783537
1   0.01   3.058824  0.457987  0.445661           0.0   -2.691352
2   0.01   4.117647  0.463487  0.463510           0.0    0.004940
3   0.01   5.176471  0.477093  0.477118           0.0    0.005103
4   0.01   6.235294  0.488035  0.488060           0.0    0.005257
5   0.01   7.294118  0.497149  0.497176           0.0    0.005392
6   0.01   8.352941  0.504940  0.504968           0.0    0.005515
7   0.01   9.411765  0.511725  0.511754           0.0    0.005632
8   0.01  10.470588  0.517729  0.517759           0.0    0.005741
9   0.01  11.529412  0.523102  0.523133           0.0    0.005840
10  0.01  12.588235  0.527961  0.527993           0.0    0.005930
11  0.01  13.647059  0.532394  0.532426           0.0    0.006012
12  0.01  14.705882  0.536465  0.536497           0.0    0.006091
13  0.01  15.764706  0.540223  0.540256           0.0    0.006168
14  0.01  16.823529  0.543711  0.543745           0.0    0.006239
15  0.01  17.882353  0.546967  0.547002           0.0    0.006306
16  0.01  18.941176  0.550017  0.550052           0.0    0.006370
17  0.01  20.000000  0.552884  0.552920           0.0    0.006431

ZM-VFNS

F2light with theory=102 using CT14llo_NF6
       x         Q2     APFEL    yadism  yadism_error  rel_err[%]
0   0.01   2.000000  0.423493  0.420175           0.0   -0.783537
1   0.01   3.058824  0.457987  0.445661           0.0   -2.691352
2   0.01   4.117647  0.463487  0.463510           0.0    0.004940
3   0.01   5.176471  0.477093  0.477118           0.0    0.005103
4   0.01   6.235294  0.488035  0.488060           0.0    0.005257
5   0.01   7.294118  0.497149  0.497176           0.0    0.005392
6   0.01   8.352941  0.504940  0.504968           0.0    0.005515
7   0.01   9.411765  0.511725  0.511754           0.0    0.005632
8   0.01  10.470588  0.517729  0.517759           0.0    0.005741
9   0.01  11.529412  0.523102  0.523133           0.0    0.005840
10  0.01  12.588235  0.527961  0.527993           0.0    0.005930
11  0.01  13.647059  0.532394  0.532426           0.0    0.006012
12  0.01  14.705882  0.536465  0.536497           0.0    0.006091
13  0.01  15.764706  0.540223  0.540256           0.0    0.006168
14  0.01  16.823529  0.543711  0.543745           0.0    0.006239
15  0.01  17.882353  0.546967  0.547002           0.0    0.006306
16  0.01  18.941176  0.550017  0.550052           0.0    0.006370
17  0.01  20.000000  0.552884  0.552920           0.0    0.006431

[juanrojochacon]

Ok nice, but now the agreement is much better and restricted to the region very close to the heavy quark threshold.

Question: do you use the internal PDF evolution or you take the PDFs from LHAPDF? At leading order the coefficient functions are trivial so the only differences come from the PDFs, what do you think?

[alecandido]

1. In our runs evolution is always disabled, because we are testing yadism only, and since the evolution is eko business we are decoupling it.
2. For F2total indeed there was something worse going on, but notice that it appeared only for FFNS5 as a further threshold (related to bottom mass), while for all the other schemes the (relative) discrepancy is pretty the same for both F2total and F2light
3. It is already strange that F2total is sensitive to any threshold in a FFNS, that should be wrong after all as pointed out by Felix, we think of F2light being sensitive as an even more unexpected event
4. We already experienced problems with LHAPDF interpolation, but in this case seems like there is no correspondence in yadism, even if we are also using LHAPDF, so there should be a further layer of strangeness in APFEL (as you pointed out at LO the SF should really be the PDF and nothing else)

[juanrojochacon]

Well, it depends on the definition of F2total in FFNS - sensu strictu, the FFNS3 can only be used for nf=3, FFNS4 for mc < Q < mb and so on. So actually in FFN schemes one never crosses hq thresholds by construction. So in summary, focusing on F2light, you guys find that

• FFNS3 is in perfect agreement
• FFNS4 exhibits a 3% different near threshold, then perfect agreement

The PDFs cannot be the case, since you use LHAPDF in both cases. So it must be related to the matching conditions. There is no other difference possible right?

Perhaps a finer scan in Q closer to threshold might provide further insight

[juanrojochacon]

Some further comments on this benchmarking:

• Why the choice of CT18LO? I think it would be better to use eg NNPDF3.1 NLO. The CT grids are sometimes not the most accurate in the world and also they don't have subgrids in the heavy quark threshold, which might cause trouble sometimes.
• Also, I would use exactly the same heavy quark values as in the input PDFs (is there any reason for not doing so?). Else one might be affected by problems close to the thresholds. So in this exercise I would take mc and mb always from the LHAPDF file that you are using consistently.

Given that the benchmarking fails only close to threshold, let's make sure we avoid all possible sources of trouble.

Also, at LO the structure functions are trivial combinations of PDFs. If you combine PDFs by hand at the same kinematics, which of the two results you reproduce?

[alecandido]

I can preview some comments, but for a full answer I would wait for @felixhekhorn :

• we would like to use LO PDFs, because we were looking at LO contributions and so we decided to restrict to LO only, to be sure to work in a limited environment (even if there should be no issue in principle in using everything else); if I remember correctly we chose CT18LO because someone told us to be more reliable than the corresponding NNPDF3.1LO
• we are not using at all the threshold values of LHAPDF, and we should have checked that APFEL neither (but maybe you can tell us more on this point); so, since in principle we are both insensitive to them, and we believe to be supposed to perform the same calculation, we decided not to use any special value, exactly because if the use of special values does matter is something that should be detected, documented and advertised to the final user (moreover we chose simple values that make it easier for us to understand the results); now that something is not working we can also try with special values as you suggested, in order to make a special investigation for the error source (but I really think that it was a good idea not to rely on them in the first place)

Also on the last point it's very easy as you said, and we are sure not to doing anything else than evaluating the PDF as you would do by hand (but we can also make the exercise of course), while APFEL it's a little bit more involved, because instead of acting on demand is previously calculating all the observables on a predefined grid, before looking at the points requested by the user, and after that is interpolating itself to provide the final answer. So:

• we are only dealing with the interpolation of LHAPDF (that we can consider a part of the PDF definition)
• APFEL adds a further interpolation layer

this makes me thinking that in this case anything funny can be happening only on the other side.

[juanrojochacon]

I can preview some comments, but for a full answer I would wait for @felixhekhorn :

• we would like to use LO PDFs, because we were looking at LO contributions and so we decided to restrict to LO only, to be sure to work in a limited environment (even if there should be no issue in principle in using everything else); if I remember correctly we chose CT18LO because someone told us to be more reliable than the corresponding NNPDF3.1LO

Might I ask who told you that? Maybe your PhD advisor, who is known to dislike NNPDF ;) ?

• we are not using at all the threshold values of LHAPDF, and we should have checked that APFEL neither (but maybe you can tell us more on this point); so, since in principle we are both insensitive to them, and we believe to be supposed to perform the same calculation, we decided not to use any special value, exactly because if the use of special values does matter is something that should be detected, documented and advertised to the final user (moreover we chose simple values that make it easier for us to understand the results); now that something is not working we can also try with special values as you suggested, in order to make a special investigation for the error source (but I really think that it was a good idea not to rely on them in the first place)

Up to a point, for example the LHAPDF grids of NNPDF are constructed using subgrids between hq thresholds, so there is a memory of that.

Also on the last point it's very easy as you said, and we are sure not to doing anything else than evaluating the PDF as you would do by hand (but we can also make the exercise of course), while APFEL it's a little bit more involved, because instead of acting on demand is previously calculating all the observables on a predefined grid, before looking at the points requested by the user, and after that is interpolating itself to provide the final answer. So:

• we are only dealing with the interpolation of LHAPDF (that we can consider a part of the PDF definition)
• APFEL adds a further interpolation layer

this makes me thinking that in this case anything funny can be happening only on the other side.

Well, or in the way you use APFEL: the fact that you don't reproduce its numbers does not mean that there is a problem, perhaps you use the wrong settings

[juanrojochacon]

For example, please see the simple example below. With these settings one gets

1.000000e-02 2.000000e+00 4.201744e-01
1.000000e-02 3.058824e+00 4.456587e-01

in good agreement with your FFNS4 numbers I think

int main()
{
APFEL::SetPerturbativeOrder(0);
APFEL::SetPDFSet("CT14llo_NF6");
APFEL::SetPoleMasses(sqrt(2), sqrt(4), 175);
APFEL::InitializeAPFEL_DIS();
const std::vector<std::pair<double, double>> kin{
{0.01, 2.000000}, {0.01, 3.058824}, {0.01, 4.117647}, {0.01, 5.176471}, {0.01, 6.235294}, {0.01, 7.294118},
{0.01, 8.352941}, {0.01, 9.411765}, {0.01, 10.470588}, {0.01, 11.529412}, {0.01, 12.588235}, {0.01, 13.647059},
{0.01, 14.705882}, {0.01, 15.764706}, {0.01, 16.823529}, {0.01, 17.882353}, {0.01, 18.941176}, {0.01, 20.000000}};
for (auto k : kin)
{
APFEL::ComputeStructureFunctionsAPFEL(sqrt(k.second), sqrt(k.second));
std::cout << std::scientific << k.first << "\t" << k.second << "\t" << APFEL::F2light(k.first) << std::endl;
}
return 0;
}

[alecandido]

Might I ask who told you that? Maybe your PhD advisor, who is known to dislike NNPDF ;) ?

I'm sorry not to be able to answer because I lost track of the info, the only thing I remember it is that the advice was restricted to the LO only, likely also because it's not so used and maybe for this reason not optimized (in a similar fashion to what it's happening with the FFNS, the main answer we get about it is that it is really little used, because most of the time APFEL is used with FONLL and we haven't yet implemented it).

Up to a point, for example the LHAPDF grids of NNPDF are constructed using subgrids between hq thresholds, so there is a memory of that.

I perfectly agree with you that it's completely possible that there is some memory of these scales, but my point was that if this is causing a huge difference in the outcome between us and APFEL this should be something to be noticed and we should think explicitly about. Maybe it's only that we are working in some extreme uninteresting regime, but better to know that such a difference is present.

Well, or in the way you use APFEL: the fact that you don't reproduce its numbers does not mean that there is a problem, perhaps you use the wrong settings

Also on this point we quite agree. The only thing the make us suspicious is that we are pretending to know what APFEL is doing without looking into his code, only on physical/definitions ground, and try to do the same blindly (i.e. without looking the code) in yadism. So we are attaching to the parameters a "physical meaning" and using the same ones in APFEL and yadism. If something is different one of the two is wrong, most of the times it's us, but after some time if we don't find our error after deep investigation and some time spent we claim a possible bug in APFEL (but of course it's completely possible that we are still wrong, after all a bug is a bug).

[alecandido]

For example, please see the simple example below. With these settings one gets

1.000000e-02 2.000000e+00 4.201744e-01
1.000000e-02 3.058824e+00 4.456587e-01

in good agreement with your FFNS4 numbers I think

int main()
{
APFEL::SetPerturbativeOrder(0);
APFEL::SetPDFSet("CT14llo_NF6");
APFEL::SetPoleMasses(sqrt(2), sqrt(4), 175);
APFEL::InitializeAPFEL_DIS();
const std::vector<std::pair<double, double>> kin{
{0.01, 2.000000}, {0.01, 3.058824}, {0.01, 4.117647}, {0.01, 5.176471}, {0.01, 6.235294}, {0.01, 7.294118},
{0.01, 8.352941}, {0.01, 9.411765}, {0.01, 10.470588}, {0.01, 11.529412}, {0.01, 12.588235}, {0.01, 13.647059},
{0.01, 14.705882}, {0.01, 15.764706}, {0.01, 16.823529}, {0.01, 17.882353}, {0.01, 18.941176}, {0.01, 20.000000}};
for (auto k : kin)
{
APFEL::ComputeStructureFunctionsAPFEL(sqrt(k.second), sqrt(k.second));
std::cout << std::scientific << k.first << "\t" << k.second << "\t" << APFEL::F2light(k.first) << std::endl;
}
return 0;
}

I can confirm that I obtain the really same result with your code and our working instance of APFEL, so whatever difference there is it is really in the settings and not in the code.

We will further investigate and report soon.

[juanrojochacon]

Excellent, very nice, glad that we find perfect agreement now! Let's investigate and indeed make sure the fully understand (and document) what is going on!

[alecandido]

Sorry, it's not really perfect agreement, in the sense that with the settings you provide me I'm obtaining your same result, but they are different from the first set we used, and with that set we obtained two different results in APFEL and yadism.

As soon as possible we will make the investigation and compare the differences in the two sets of settings (sorry for the pun).

[juanrojochacon]

ok, but this means that the differences are on the settings, rather than some intrinsic bug, which is always a good piece of news

[alecandido]

Ok, we used your code to run a small set of benchmarks with the settings you provided us.
We found the following:

1. F2light is depending on the mc value (actually we are using mc=2, and not `mc^2=2, this was one difference in the snippet)
2. F2light above charm threshold Q2 > mc is in agreement with our F2total below that threshold (the original post of the issue was reporting the output of F2total, we discover this because instead was computing the result for F2light)

Note: we assume that F2light means u, d, s, this is why we believe there should be really no reason for F2light to depend on mc