MadGraph5_aMC@NLO

Different LO pT distributions generated by the LO and NLO interface for t t~ + j production

Asked by Marco Hufnagel

Hello,

I try to generate LO events for the process ‘t t~ j’ with both the LO and the NLO interface in MadGraph 2.6.4 (i.e. in the latter case I use the LO mode in the NLO interface). In both cases, I use Pythia8 for the parton shower and Delphes for the detector simulation. However, when I plot the resulting pT distributions after the detector simulation, I find that both distributions (from the LO interface and the LO mode of the NLO interface) are rather different. More precisely, depending on the bin, both distributions differ by ~100%.
I find this result a little bit surprising, as I (hopefully) made sure to use the same input parameters in both run_card’s. For example,. I did choose the same pdf for both calculations and also the same identifier for the dynamic scale (3 in both cases). Furthermore, I even adjusted the cone-radius for the jet definition and the rapidity cut an the leading jet in the NLO run_card. However, the pT distributions are still different; even though the cross-sections turn out to be the same.
So my question is: Is there any reason why the distributions are not the same? Is there any difference when calculating LO events in the NLO interface compared to just using the LO interface?

Thank you in advance!

Cheers,
Marco

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
marco zaro Edit question
Solved by:
Rikkert Frederix
Solved:
Last query:
Last reply:
Revision history for this message
marco zaro (marco-zaro) said : 		#1

Hi Marco,
when you write pT distribution, you refer to the pT of which object?
Then, given that you get the same cross section, I suspect the difference lies in the scalup entry (the shower-starting scale, i.e. the maximum hardness of the radiation that pythia can generate) or other shower settings.
Can you please plot the variable scalup (which can be read directly from the event files) in both cases and compare the two distributions?
Also, can you please check the input files of pythia8 to see if there are differences?
Let me know
ciao,

Marco

Revision history for this message
Marco Hufnagel (skumblex) said : 		#2

Hi Marco,

thanks a lot for your quick response.

> "when you write pT distribution, you refer to the pT of which object?"

I refer to the pT of the leading jet at detector level. Sorry, I should have stated that before.

> "Also, can you please check the input files of pythia8 to see if there are differences?"

I find it quite hard to compare the input settings in both interfaces, as there only is a pythia8_card in case of the LO interface and a more general shower_card for the NLO interface. I know that at NLO, I can find the Pythia8.cmd file in <FOLDER>/McatNLO/RUN_PYTHIA8_1. However, there does not seem to be an equivalent file in case of the LO interface. At least a simply grep only returned the .cmd file in the Events folder which seems to be a simple copy of the pythia8_card.
So what I tried is to copy the Pythia8.cmd file from the NLO interface and to use it as the pythia8_card in the LO interface. In fact, this run finished without problems, but still the pT distributions look different (in fact nothing changed at all, up to some statistical fluctuations). So I guess, there is no problem with the Pythia8 settings?

> "Can you please plot the variable scalup (which can be read directly from the event files) in both cases and compare the two distributions?"

I am am not sure if I found the correct variable, but there is a property called scalup in the LHEFEvent branch of Delphes, which encodes the scale in GeV used in the calculation of the PDFs in the event. Is this the correct variable?
I did plot the distributions of this variable using both the LO and the NLO interface and both of them look quite different. In fact, those events that where generated by the NLO interface have a constant scalup of ~0.078, while the events from the LO interface are peaked around ~0.0084. So this might be a potential problem!

Thanks again for your help!

Cheers,
Marco

Revision history for this message
marco zaro (marco-zaro) said : 		#3

Hi Marco,
thanks for your answer
>
> I am am not sure if I found the correct variable, but there is a property called scalup in the LHEFEvent branch of Delphes, which encodes the scale in GeV used in the calculation of the PDFs in the event. Is this the correct variable?

I think so, even though I do not understand what PDFs have to do here

> I did plot the distributions of this variable using both the LO and the NLO interface and both of them look quite different. In fact, those events that where generated by the NLO interface have a constant scalup of ~0.078, while the events from the LO interface are peaked around ~0.0084. So this might be a potential problem!
what is the unit for the numbers that you quote? I expect scalup to be in the ballpark of ~100 gev or so for this process...
cheers,

Marco

>
> Thanks again for your help!
>
> Cheers,
> Marco
>
> --
> You received this question notification because you are subscribed to
> the question.

Revision history for this message
Marco Hufnagel (skumblex) said : 		#4

Hey,

> "what is the unit for the numbers that you quote?"

according to the documentation, the unit is GeV, so probably it is not the correct variable.

However, according to the LHE documentation, there also is a SCALUP variable in the LHE file itself. This variable is of the order of 100GeV. But still, the distributions of this variable are different when comparing the LO and the NLO interface. In the LO interface, the SCALUP is always above 180GeV and in the NLO interface, it is above 17GeV. Afterwards both distributions fall off exponentially. Maybe 1% of all NLO interface events have a SCALUP above 200GeV.

So according to what you said, I guess the results from the LO interface are more reasonable?

Cheers,
Marco

Revision history for this message
Marco Hufnagel (skumblex) said : 		#5

Hi again,

I just did a plot of the pT of generated final-state jet at parton level and these distributions are the same up to statistical fluctuations. So the only difference in the .lhe files generated by the LO and the NLO interface is the value of SCALUP. This variable then seems to result in different Pythia8 output even though the Pythia8 input parameters are the same.

So is there a reason why the SCALUP variable is different in the LO and the NLO interface?

Cheers,
Marco

Revision history for this message
marco zaro (marco-zaro) said : 		#6

Hi Marco,
thanks for the update. From this further check it really seems that the differences are driven by scalup
I think that the different choice of the scalup value is based on the different scope (NLO matching vs LO prediction, + merging optionally) of the two codes.
With the NLO code, you will anyway have the real emission that will fill the phase space, so you can keep the scale quite low. At LO instead, you pick a larger scale to fill more the phase space.
To me, both choices seem not unreasonable, and the difference should be possibly considered as an uncertainty. Can you please put somewhere the plot with the parton-level prediction and the two showered ones?
Thanks!
cheers,

Marco

> On 14 Mar 2019, at 16:22, Marco Hufnagel <email address hidden> wrote:
>
> Question #679144 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/679144
>
> Marco Hufnagel gave more information on the question:
> Hi again,
>
> I just did a plot of the pT of generated final-state jet at parton level
> and these distributions are the same up to statistical fluctuations. So
> the only difference in the .lhe files generated by the LO and the NLO
> interface is the value of SCALUP. This variable then seems to result in
> different Pythia8 output even though the Pythia8 input parameters are
> the same.
>
> So is there a reason why the SCALUP variable is different in the LO and
> the NLO interface?
>
> Cheers,
> Marco
>
> --
> You received this question notification because you are subscribed to
> the question.

Revision history for this message
marco zaro (marco-zaro) said : 		#7

. At LO instead, you pick a larger scale to fill more the phase space. <<— This should be read as “With the LO code, instead"

> On 14 Mar 2019, at 16:22, Marco Hufnagel <email address hidden> wrote:
>
> Question #679144 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/679144
>
> Marco Hufnagel gave more information on the question:
> Hi again,
>
> I just did a plot of the pT of generated final-state jet at parton level
> and these distributions are the same up to statistical fluctuations. So
> the only difference in the .lhe files generated by the LO and the NLO
> interface is the value of SCALUP. This variable then seems to result in
> different Pythia8 output even though the Pythia8 input parameters are
> the same.
>
> So is there a reason why the SCALUP variable is different in the LO and
> the NLO interface?
>
> Cheers,
> Marco
>
> --
> You received this question notification because you are subscribed to
> the question.

Revision history for this message
Marco Hufnagel (skumblex) said : 		#8

Sure, here are the pT distributions at parton and detector level as well as the scalup distributions: https://www.dropbox.com/s/tv73fa5awlplyif/679144.tar.xz?dl=0

But if we consider it as an error, isn't this error quite large. Say, I would perform a cut on pT at detector level of 150GeV. Then I would end up with ~1.4 times more events from the LO interface than I get from the NLO interface. This goes beyond the PDF uncertainty of ~5% and is in the same ballpark as the scale uncertainty.

So shouldn't this be taken into account whenever someone uses the NLO interface to generate LO events?

Thanks again for your help!

Cheers,
Marco

Revision history for this message
marco zaro (marco-zaro) said : 		#9

Hi Marco,
thanks for the plots. Well, given that the computation is LO, a 40-50% (or even more) uncertainty is not a surprise. You should not compare it to PDF uncertainties, as these come from completely different sources, rather to scale uncertainties (after all, scalup is the shower scale). As you said, the latter are comparable with what you get, so I do not see anything particular suspect here. If you want to reduce this uncertainty, use NLO predictions, it shouldn’t be terribly slow for tt+jet.
On whether one should use the NLO interface to generate LO events: this possibility is there for practical reasons, in order to have the possibility to compare LO and NLO events generated with exactly the same (code and) setup for input parameters, shower settings, etc.
Let me know if you need more help.
Cheers,

Marco

> On 15 Mar 2019, at 12:26, Marco Hufnagel <email address hidden> wrote:
>
> Question #679144 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/679144
>
> Status: Answered => Open
>
> Marco Hufnagel is still having a problem:
> Sure, here are the pT distributions at parton and detector level as well
> as the scalup distributions:
> https://www.dropbox.com/s/tv73fa5awlplyif/679144.tar.xz?dl=0
>
> But if we consider it as an error, isn't this error quite large. Say, I
> would perform a cut on pT at detector level of 150GeV. Then I would end
> up with ~1.4 times more events from the LO interface than I get from the
> NLO interface. This goes beyond the PDF uncertainty of ~5% and is in the
> same ballpark as the scale uncertainty.
>
> So shouldn't this be taken into account whenever someone uses the NLO
> interface to generate LO events?
>
> Thanks again for your help!
>
> Cheers,
> Marco
>
> --
> You received this question notification because you are subscribed to
> the question.

Revision history for this message
Best Rikkert Frederix (frederix) said : 		#10

Hi all,

The difference in the two predictions for this process (i.e., using the LO code, versus using the NLO code at LO) can indeed be solely attributed to a difference in the SCALUP value. This is the starting scale for the shower. In the LO code, this is set to be related to the hard scale of the process, which is of the order of a couple of 100 GeV or so. In the NLO code, this is set to the pT(jet) instead, hence a much smaller scale. Both options are reasonable and one can find theoretical arguments that argue in either way. However, when you do not use any merging to include the ttbar+0j sample, the pT(jet) scale choice is more natural. Hence, in this particular case, I would opt to use the NLO interface at LO accuracy.

However, remember that below 50 GeV or so for the jet, it is not obvious what the best way to describe that jet is: you can use ttbar+jet matrix elements (as you have been doing), or you can use ttbar matrix elements and let the shower generate the first jet. The latter is obviously superior when jets are very soft, while the former is superior when the jets are hard. The transition region should be around 50 GeV or so. The merging of different samples (a la MLM, CKKW, or FxFx) has been exactly designed to have a smooth transition between the two descriptions and have a consistent and optimised description over the whole spectrum. Therefore, I would really recommend to use these merging prescriptions (including variations the merging scale!), even if you always require the jet to be there at the analysis level.

Best regards,
Rikkert

Revision history for this message
Marco Hufnagel (skumblex) said : 		#11

Hi thanks for the answer (and sorry for the late reply).

Great, than I will consider the difference as an additional systematic uncertainty.

However, I have one last question. In order to estimate the size of this uncertainty, is it possible to read the lhe file, change all of the scalup entries and afterwards run the shower again. Or does this lead to some inconsistencies in the computation?

Best regards,
Marco

Revision history for this message
Rikkert Frederix (frederix) said : 		#12

Hello Marco,

For leading order events that should be alright. For NLO accurate events certainly not.

Best,
Rikkert

Revision history for this message
Marco Hufnagel (skumblex) said : 		#13

Ok great. Thanks!

Revision history for this message
Marco Hufnagel (skumblex) said : 		#14

Thanks Rikkert Frederix, that solved my question.