MadGraph5_aMC@NLO

SCALUP and shower_scale_factor in NLO simulation

Asked by Sung Hak Lim

Dear MG5 team,

May I know how shower_scale_factor in run_card of NLO simulation works in detail?

It looks like first setting min and max scale for this from subroutine assign_scaleminmax in Template/NLO/Subprocess/montecarlocounter.f, by

xscalemin = max( shower_scale_factor * 0.1 * HT/2 , 10.0)
xscalemax = min( max( shower_scale_factor * 1.0 * HT/2, xscalemin + 20.0 ), 2 Sqrt( E_beam1 * E_beam2 ) )

subroutine set_shower_scale in Template/NLO/Subprocess/fks_singular.f saves SCALUP to send shower starting scale to Pythia8

S-event
   SCALUP = min( xscalemax, shower_S_scale )
H-event
   SCALUP = min( xscalemax, max( shower_H_scale , ref_H_scale - min (emsca, xscalemax) )

shower_S_scale and shower_H_scale seem to be a kT distance between two partons which will be merged at next step in kt clustering when I check subroutine set_shower_scale_noshape.

The question is: if there is a light-parton in S-event, for example, p p > t t~ j [QCD] and j have smaller pt than HT/2, then does shower_scale_factor do nothing when we generate showering?

I guess this is related to aMC@NLO matching part in pythia8 but I want to make sure.

Best wishes,
Sung Hak

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
Paolo Torrielli Edit question
Solved by:
Paolo Torrielli
Solved:
Last query:
Last reply:
Revision history for this message
Paolo Torrielli (paolotorriell) said : 		#1

Dear Sung Hak,

note that HT/2 is only the reference scale for the dampening profile.

From the code (routine set_shower_scale in fks_singular.f), I see that
first SCALUP is assigned to min(emsca,scalemax), where emsca is a
quantity extracted randomly, according to a given distribution, in the range
[scalemin, scalemax] (see routine assign_emsca in montecarlocounter.f).
In principle min(emsca,scalemax) should always be equal to emsca.
Then SCALUP = min(emsca, shower_S_scale).

If now you change shower_scale_factor in run_card, the range in which
emsca is extracted will change, and consequently the SCALUP assignment,
even if the jet pT is smaller than HT/2, precisely because emvca is not HT/2.

Cheers.
Paolo

Revision history for this message
Sung Hak Lim (sunghak-lim) said : 		#2

Dear Paolo,

For emsca selected case, I agree with you.

I also checked that emsca is assigned in range [scalemin, scalemax] with emscainv, which adjust random number generation focussing on center.

But what if shower_S_scale < emsca?

For p p > t t~ j [QCD], if generator level jet has pt, i.e. kt distance to beam, less than emsca, then set_shower_scale will look for shower_S_scale. I cannot find any shower_scale_factor dependence in subroutine set_shower_scale_noshape in fks_singular.f and that's where I'm curious now.

Best wishes,
Sung Hak

Revision history for this message
Sung Hak Lim (sunghak-lim) said : 		#3

Dear Paolo,

By the way, I just noticed that MG5 using emscainv

(r - Sqrt[(r - r^2)])/(2 r - 1)

which have potential to cause unwanted emscainv selection due to floating point error near r = 0.5 .

It seems it will be cured internally in other subroutine, such as taking scalemax instead. However, this will break smooth random number choice so I think it may generate unwanted flaws.

Isn't it better to use floting point arithmetic safe expression, like

Sqrt[r]/(Sqrt[r] + Sqrt[1 - r])

Best wishes,
Sung Hak

Revision history for this message
Best Paolo Torrielli (paolo-torrielli) said : 		#4

Dear Sung Hak,

> But what if shower_S_scale < emsca?
If shower_S_scale < emsca, then SCALUP = shower_S_scale.
Of course the distribution of SCALUP depends on shower_scale_factor,
since emsca does, thus min(emsca,shower_S_scale) does, but
there is no explicit dependence on shower_scale_factor coming
from shower_S_scale.

Cheers.
Paolo

Revision history for this message
Sung Hak Lim (sunghak-lim) said : 		#5

Dear Paolo,

Thanks for the clarification. So the conclusion seems that SCALUP has shower_scale_factor dependence in general but shower_S_scale chosen case has no explicit shower_scale_factor dependence.

For floating point issue, I may open a separate thread.

Best wishes,
Sung Hak

Revision history for this message
Sung Hak Lim (sunghak-lim) said : 		#6

Thanks Paolo Torrielli, that solved my question.

Revision history for this message
Paolo Torrielli (paolo-torrielli) said : 		#7

Dear Sung Hak,
thanks for your suggestion, I think what you propose is fine.
Cheers.
Paolo

> On 2 Nov 2017, at 10:05, Sung Hak Lim <email address hidden> wrote:
>
> Question #660114 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/660114
>
> Sung Hak Lim gave more information on the question:
> Dear Paolo,
>
> By the way, I just noticed that MG5 using emscainv
>
> (r - Sqrt[(r - r^2)])/(2 r - 1)
>
> which have potential to cause unwanted emscainv selection due to
> floating point error near r = 0.5 .
>
> It seems it will be cured internally in other subroutine, such as taking
> scalemax instead. However, this will break smooth random number choice
> so I think it may generate unwanted flaws.
>
> Isn't it better to use floting point arithmetic safe expression, like
>
> Sqrt[r]/(Sqrt[r] + Sqrt[1 - r])
>
> Best wishes,
> Sung Hak
>
> --
> You received this question notification because you are subscribed to
> the question.