Showering with Pythia8 in NLO run

Asked by Saurabh Niyogi

Hi,

 I have a few questions regarding NLO process generation in aMC@NLO.

 I am using latest (v2.3.3) MG5 version interfaced with Pythia8186. It is running fine but I do not find the showered events. There is a zipped file in Events/run_01/ directory named events_PYTHIA8_0.hepmc.gz which is empty. I just give proper path (pythia8_path) inside amcatnlo_configuration.txt and ask run_card to use PYTHIA8 for showering. Is that all I need to do ? HepMC is also installed which is linked to Pythia8, as I can generate HepMC output using standalone Pythia8186.

  My next question is regarding NLO-PS matching. For NLO event generation with showering, does matching (or merging ) become obvious ? I mean without matching NLO process does not make sense, does it ? If yes, then for e.g. ttbar event generation @NLO
generate p p > t t~ [QCD]
add process p p > t t~ j [QCD]
and then match. Is this correct that we have to do both even if we want ttbar process but at NLO.

I am asking this since in tt~ NLO event generation (with ickkw = 0 ), it prints message
============
INFO: Starting run
INFO: Cleaning previous results
INFO: Doing NLO matched to parton shower
============

Thanks a lot for your help.

Regards,
Saurabh

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 (paolo-torrielli) said :
#1

Dear Saurabh,

as far as the Pythia8 question, you should be using Pythia8210 or later.
Previous versions of Pythia8 are either not supported by our code any
longer, or contain glitches for the FxFx interface. Everything should go
smoothly with a new version of Pythia8 (I don't see anything wrong in
your procedure).

The second question is a bit less clear to me. Let me first set up a bit of
nomenclature. We call NLO+PS 'matching' the combination of a fixed-order
NLO computation with a parton shower.
By typing for example 'generate p p > t t~ [QCD]', you instruct the code
to include NLO QCD corrections to the Born process p p > t t~, and by
toggling the options in the subsequent python shell, you choose to run
a fixed NLO or an NLO+PS simulation.
The fixed NLO simulation does make sense in the hard regions of the phase
space, and for observables dominated by this kinematics, while the NLO+PS
gives a reliable coverage also in soft/collinear regions of the phase space.
So, summarising, 'generate p p > t t~ [QCD]' is ttbar @ NLO, if this is what
you want (i.e. the [QCD] statement means QCD NLO corrections).

When you instead specify 'generate p p > t t~ [QCD] @0; add process p p > t t~ j [QCD] @1'
(note the @0, and @1 at the end of the line), you are generating two NLO+PS
samples that are then 'merged' together with the FxFx (ickkw=3) or UNLOPS
(ickkw=4) prescription, namely ttbar and ttbar+jet both @ NLO, combined in
such a way as not do double count the common configurations.
This gives a yet better description of observables dominated by jets and by very
hard emissions, since you include more and more matrix-element information
in the simulation.

Cheers,
Paolo

Revision history for this message
Saurabh Niyogi (saurabh12102003) said :
#2

Hi Paolo,

  Thanks a lot.

 http://amcatnlo.web.cern.ch/amcatnlo/FxFx_merging.htm suggests to use Pythia 8.186 or later. Anyway, this is fine.

 I am really confused with the NLO QCD correction part. When we calculate NLO QCD corrections to Born process p p > t t~, this includes real emission diagrams as well. Is this different from p p > t t~ j process ? May be I am confusing between real emission and hard scattering with an extra jet.

 Thanks for your help.

Regards,
Saurabh

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

Hi Saurabh,

> http://amcatnlo.web.cern.ch/amcatnlo/FxFx_merging.htm suggests to use
> Pythia 8.186 or later. Anyway, this is fine.
You’re right, we should update the webpage.

> I am really confused with the NLO QCD correction part. When we
> calculate NLO QCD corrections to Born process p p > t t~, this includes
> real emission diagrams as well. Is this different from p p > t t~ j
> process?
When you ‘generate p p > t t~ [QCD] @0’, you are including diagrams with
a tt final state (Born and virtual), and diagrams with a ttj final state
(real emission).

The further command 'add process p p > t t~ j [QCD] @1’, specifies to add
a new process where the Born has a ttj final state, so the new diagrams
you’re including have ttj final state (Born and virtual of this new process),
and ttjj final state (real emission of this new process).

Since, as you correctly say, the real emission of p p > t t~ is the Born of
p p > t t~ j, a method to avoid double-counting these contributions is needed,
which is part of what the FxFx method does.

Cheers.
Paolo

Revision history for this message
Saurabh Niyogi (saurabh12102003) said :
#4

Ok ok , I understand.

 Just nagging one last time. This double counting (the one you mentioned above) is different from ME-PS double counting. Is it ? Something like this is written in the run_card. ickkw = 3 takes care of both merging at hard scattering level and also matching at the shower level. Is this correct ?

 No more questions, I swear :)

Thanks a lot.

Saurabh

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

Hi Saurabh,

> Just nagging one last time. This double counting (the one you
> mentioned above) is different from ME-PS double counting. Is it ?
Exactly. For example, FxFx paper hep-ph/1209.6215 explains this
in detail at page 8, below eq. (2.11).

> Something like this is written in the run_card. ickkw = 3 takes care of
> both merging at hard scattering level and also matching at the shower
> level. Is this correct ?
Yes, and for consistency when you want to use ickkw = 3 you have
to select

2 Fixed order (no event generation and no MC@[N]LO matching): fixed_order=OFF

in the shell menu you’re prompted with when you do 'launch'.

Cheers.
Paolo

Revision history for this message
Saurabh Niyogi (saurabh12102003) said :
#6

Okk, Thanks.

Revision history for this message
Saurabh Niyogi (saurabh12102003) said :
#7

Thanks Paolo Torrielli, that solved my question.