# SCALUP and shower_scale_factor in NLO simulation

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/

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/

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_

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

- Assignee:
- Paolo Torrielli Edit question

- Solved by:
- Paolo Torrielli

- Solved:
- 2017-11-03

- Last query:
- 2017-11-03

- Last reply:
- 2017-11-02

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,

quantity extracted randomly, according to a given distribution, in the range

[scalemin, scalemax] (see routine assign_emsca in montecarlocount

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

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_

Best wishes,

Sung Hak

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

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_

since emsca does, thus min(emsca,

there is no explicit dependence on shower_scale_factor coming

from shower_S_scale.

Cheers.

Paolo

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

Sung Hak Lim (sunghak-lim) said : | #6 |

Thanks Paolo Torrielli, that solved my question.

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:/

>

> 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.