-
Notifications
You must be signed in to change notification settings - Fork 9
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
DIS: structure functions in low Q2 regime seems wrong #22
Comments
@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. |
Unfortunately also the light structure functions are affected FFNS3F2light 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 FFNS4F2light 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 FFNS5F2light 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-VFNSF2light 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 |
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? |
|
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
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 |
Some further comments on this benchmarking:
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? |
I can preview some comments, but for a full answer I would wait for @felixhekhorn :
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:
this makes me thinking that in this case anything funny can be happening only on the other side. |
Might I ask who told you that? Maybe your PhD advisor, who is known to dislike NNPDF ;) ?
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.
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 |
For example, please see the simple example below. With these settings one gets 1.000000e-02 2.000000e+00 4.201744e-01 in good agreement with your FFNS4 numbers I think int main() |
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).
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.
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). |
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. |
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! |
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). |
ok, but this means that the differences are on the settings, rather than some intrinsic bug, which is always a good piece of news |
Ok, we used your code to run a small set of benchmarks with the settings you provided us.
Note: we assume that |
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
FFNS3
FFNS4
FFNS5
ZM-VFNS
The text was updated successfully, but these errors were encountered: