Integration grid for MadEvent and standard cuts

Asked by Stefan Prestel

Hi all,

I've encountered a funny behaviour when supplying ATLAS people with a MadGraph5/MadEvent version with user-defined kT-(Durham) cut - as is useful to allow for Pythia8 to do CKKW-L merging internally. So far, for merging purposes (and I don't mean the old analytic version that is accessible inside MadEvent, but the full CKKW-L in Pythia8), I've used MadGraph4/MadEvent - mostly since I was used to it.

However, there's a complication when using MadGraph5/MadEvent. Clearly, when defining a merging scale, the merging scale definition and value should be more restrictive than any other cut in the event, otherwise the phase space coverage will be compromised. Thus, in MadGraph4/MadEvent, I've set all standard cuts to extremely low values, implemented a user cut and generated files. Plotting as many independent observables as possible, I indeed saw that the phase space was covered nicely and the ME regularised.

Now, when moving to MadGraph5 (v. 1.4.5 and v. 1.4.6, from last week), the standard cuts are much more intertwined with the phase space generation (over myamps.f), so that setting them to low values might be critical when divergences need to be regularised. However, in good faith, I still tried the following:

Implement kT cut in cuts.f

A
Set ptj = 30
Generate ME for pp> e+ ve j by ./bin/newprocess_mg5
Set kt-cut = 30
Generate events ptmin30kt30.lhe
Set ptj= 0, Set kt-cut = 30
Generate events ptmin0kt30.lhe

B
Set ptj = 0
Generate ME for pp> e+ ve j by ./bin/newprocess_mg5
Set kt-cut = 30
Generate events ptmin0kt30-2.lhe
Set ptj= 30, Set kt-cut = 30
Generate events ptmin0kt30-2.lhe

Comparing e.g. the pt of the jet between these samples, I see that ptmin30kt30.lhe, ptmin0kt30.lhe and ptmin30kt30.-2lhe match (since for a single jet, ptj = kt, of course), while ptmin0kt30-2.lhe is different!

The problem seems to be in what is used which cut is used in the integration grids, since clearly, we need a cut to regularise the jet. It seems the way the grid is re-read if you don't run newprocess again is causing problems.

I didn't want to send this as a bug report, since the reason for the behaviour is (somewhat) clear. However, it might be nice to aviod such problems.

I'd gladly send you a copy of the code I added (since I assume you want to make sure the problem is not my doing :) ), as well as the LHE files produced.

Since the ATLAS people want to include CKKW-L in Pythia8 into their software framework, I'd be happy about a quick answer. (I hope this is the right channel to send to - I didn't want to bother a particular one of you with questions right away, without giving you the chance to dodge them :P ).

Cheers,
Stefan

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
Johan Alwall (johan-alwall) said :
#1

Hello Stefan,

Did you set auto_ptj_mjj to F in the run_card? By default, it is true.

#*********************************************************************
# Automatic ptj and mjj cuts if xqcut > 0
# (turn off for VBF and single top processes)
#**********************************************************
   T = auto_ptj_mjj ! Automatic setting of ptj and mjj

All the best,
Johan

Revision history for this message
Johan Alwall (johan-alwall) said :
#2

Hello agan Stefan,

In fact, reading your message again, probably that's not the problem. Could you in fact send me your modifications (alwall _at_ fnal.gov)?

Thanks,
Johan

Can you help with this problem?

Provide an answer of your own, or ask Stefan Prestel for more information if necessary.

To post a message you must log in.