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

Fix bug in the definition of the 1D luminosity. #1443

Merged
merged 9 commits into from
Oct 28, 2021
Merged

Fix bug in the definition of the 1D luminosity. #1443

merged 9 commits into from
Oct 28, 2021

Conversation

enocera
Copy link
Contributor

@enocera enocera commented Oct 26, 2021

This PR addresses #1442 (see explanation there). A quick computation of the gg 1D luminosity plot (see attachment) reveals that it is the same as the one computed with APFELweb.
validphys
APFELweb
Additional checks must be carried out to verify that luminosities are indeed defined as in Eqs. (9.1)-(9.2)-(9.3) of the NNPDF4.0 paper.

@Zaharid
Copy link
Contributor

Zaharid commented Oct 26, 2021

If this is to work for both 1d and 2d sets shouldn't we remove all the denominators and apply them in the corresponding functions. AFAICT this implementation has a factor tau compared to the equations.

@enocera
Copy link
Contributor Author

enocera commented Oct 26, 2021

@Zaharid That is correct. And that's the reason why this PR is WIP.

@enocera
Copy link
Contributor Author

enocera commented Oct 26, 2021

Also, as you were mentioning in #1442 (comment), I'm not 100% sure that the definitions of the luminosity channels correspond to those written in the NNPDF4.0 paper.

@enocera enocera self-assigned this Oct 26, 2021
@enocera enocera added the bug Something isn't working label Oct 26, 2021
@enocera
Copy link
Contributor Author

enocera commented Oct 26, 2021

I've carefully checked the definitions of parton luminosities implemented in validphys. I have concluded that these are as in Eqs.(1-4) of https://arxiv.org/pdf/1607.01831.pdf which, in my opinion, are the expression that we should use. I assume that Eqs. (9.1-9.3) in the NNPDF4.0 paper are meant to denote the same thing, even if they are written in a sloppier way (in my opinion).
I've redefined the way in which we integrate the 2D luminosity to obtain the 1D luminosity. I think it's more transparent to use the rapidity as integration variable (instead of x1) and so I did. I've redone the affected luminosity plots that appear in the NNPDF4.0 paper:

Fig 9.2 is not affected, as it should, and as I've explicitly checked.

@enocera enocera changed the title [WIP] Fix bug in the definition of the 1D luminosity. Fix bug in the definition of the 1D luminosity. Oct 26, 2021
@Zaharid
Copy link
Contributor

Zaharid commented Oct 28, 2021

With these settings I now get a warning running one of the examples.

meta:
  title: Luminosity plot example
  author: Rosalyn Pearson
  keywords: [example]

pdfs:
  - {id: "NNPDF31_nlo_as_0118", label: "3.1 NLO"}
  - {id: "NNPDF31_nnlo_as_0118", label: "3.1 NNLO"}
  - {id: "NNPDF31_nnlo_as_0118_DISonly", label: "3.1 DIS only NNLO"}

pdf: {id: "NNPDF31_nlo_as_0118", label: "3.1 NLO"}

sqrts: 13000 # GeV

lumi_channel: "gg" # one of [gg, gq, qqbar, qq, ddbar, uubar, ssbar,
                   #         ccbar, bbbar, dubar, udbar, scbar, csbar, pp, gp]

PDFscalespecs:
  - xscale: log
    xscaletitle: Log

template_text: |
  {@with PDFscalespecs@}
  {@xscaletitle@} scale
  =====================
  {@plot_lumi1d@}
  {@plot_lumi1d_uncertainties@}
  {@endwith@}

actions_:
  - report(main=True)
/home/zah/nngit/nnpdf/validphys2/src/validphys/pdfgrids.py:205: IntegrationWarning: The maximum number of subdivisions (50) has been achieved.
  If increasing the limit yields no improvement it is advised to analyze 
  the integrand in order to determine the difficulties.  If the position of a 
  local difficulty can be determined (singularity, discontinuity) one will 
  probably gain from splitting up the interval and calling the integrator 
  on the subranges.  Perhaps a special-purpose integrator should be used.
  res = integrate.quad(f, y_min, y_max, epsrel=1e-5, limit=50)[0]

Do we really need 1e-5 in error?

@enocera
Copy link
Contributor Author

enocera commented Oct 28, 2021

Do we really need 1e-5 in error?

That was more or less my question yesterday; I have the feeling that 1e-5 is a little extreme and that we can have something between 1e-3 and 1e-4. Actually, it's hard to spot any difference in the plots if you increase the error to 1e-3.

@Zaharid
Copy link
Contributor

Zaharid commented Oct 28, 2021

I think that would make sense. 1e-5 seems much more than the various interpolations we have anyway.

Make sure the check works also with the default value for mxmax.

Make sure the default is consistent in the check and function.
@Zaharid
Copy link
Contributor

Zaharid commented Oct 28, 2021

@enocera ok to merge this?

@enocera enocera merged commit 4603ffd into master Oct 28, 2021
@enocera enocera deleted the fix_1Dlumi branch October 28, 2021 11:46
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

Successfully merging this pull request may close these issues.

2 participants