Shower scale in single top t channel

Asked by Benedikt Maier

Dear experts,

I am generating the single top t-channel at NLO

p p > t b~ j $$ w+ w- [QCD]

Now, for the official sample production of the CMS collaboration we have hit a point where we might need advise and help from authors.

Let me briefly explain the situation:

We use a customized setscales.f (https://github.com/cms-sw/genproductions/blob/master/bin/MadGraph5_aMCatNLO/cards/production/13TeV/st_tch_4f_ckm_hwpp_NLO/st_tch_4f_ckm_hwpp_NLO_setscales.f)

to take the spectator b kinematics into account.

The nominal sample is showered with Pythia8, and we do not encounter any problems with showering there.
However, we also want a systematic sample showered with Herwig++. (i.e. just exchanging PYTHIA8 with HERWIGPP in the run_card.dat).

When we try and shower the so produced aMCatNLO events with H++, we sooner or later hit an event where Herwig++ jumps into an infinite loop and does not proceed to the next event!

After carefully investigating when this happens, we found out that in all such cases the starting scale of the shower is exactly 3.
I looked into the code, and it seems the scale is set in the set_shower_scale routine of the fks_singular.f, where the following final check is performed

SCALUP(iFKS)=max(SCALUP(iFKS),3d0)

This means, before this, the SCALUP(iFKS) was smaller than 3.

Now, I have basically three questions:

1) (Probably rather a question to the H++ authors, but who knows ...) Do you know why Herwig++ is jumping into an infinite loop (it seems it dies in endless LHAPDF calls) with such events?

2) Do you know why, when generating 1M events with the run_card setting PYTHIA8 and HERWIGPP respectively, there are

326 events for PYTHIA8 where the shower scale is exactly 3

but

4674 events for HERWIG++ where this is the case? (Sometimes the problem occurs only after many many thousand events of the 1M, so there must be events with a shower scale of 3 where Herwig doesnt have problems!)

3) How exactly is the shower scale determined? For the leading order code of madgraph, it is always equivalent to the renormalization scale, but this is not the case for NLO ... otherwise one would never get to a 3 here, because the b mass is entering the renormalization scale formula, so this scale is at least 4.7 GeV. (and I have checked this with a minimal example of p p > t t~ as well that the shower scale and ren. scale are only identical when using the LO code, but not at NLO).

and maybe as a fourth question:

What would be the way you'd suggest to proceed? Like this, at the moment we just cannot produce aMCatNLO + Herwig++ events for single top in CMS ... The Powheg t channel in the 4fs works with Herwig++. There is no such an event where Herwig++ jumps into the infinite loop! ...

Thanks in advance for the help, in particular on behalf of CMS!

Benedikt

PS: All the necessary information besides the setscales.f can be found in:

https://github.com/cms-sw/genproductions/tree/master/bin/MadGraph5_aMCatNLO/cards/production/13TeV/st_tch_4f_ckm_hwpp_NLO

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Stefano Frixione (stefano-frixione) said :
#1

Dear Benedikt,
there's no direct relationship between the hard scales (fact and ren) and the shower scale.
The latter is only very loosely governed by the former two, since it is determined dynamically
given the event kinematics, which in turn is somewhat dependent on scale choices.
The fact that with Py8 and HW++ you get different number of events with small shower
scales is due to the fact that the short-distance cross sections are different in the two
cases, and this implies different kinematic configurations. From what you say, however,
we're still talking about a small fraction of events with a small scale.

Concerning your questions:
1) It is clearly a bug in HW++; I think you should report it to the authors. I have no clue
 as to why this happens.
2) See above for the differences between the two MCs. It is normal, and it happens
 for all processes.
3) There is a description in 1405.0301 (page 47 and top of page 48).
4) Since I don't know what causes the problem in HW++, it's not easy to say.
 One possibility is to change that 3 to 3.1 or something like this (ie not an "integer"),
 but I doubt this works. Another is that of trying and run HW++ by changing seed;
 if the problem repeats itself exactly at the same event, then one could just throw
 that event away by hand (ie eliminate it from the event file before showering).
 Clearly, these are temporary patches while we try and understand something more.
 I'll discuss this issue with a few people in the collaboration and some HW++ authors,
 and follow up with you. If you have any further information, let me know
(for example, I'm not sure I can find the input cards in the documentation
you have linked. Those might be important).
Cheers, Stefano.

Can you help with this problem?

Provide an answer of your own, or ask Benedikt Maier for more information if necessary.

To post a message you must log in.