DS/DR scheme in madgraph
Hello I'm interested in a study that involves ttbar and single tW production at 13 TeV at NLO, It has been noticed recently that due to interference between ttbar and tW and due to offshell effects that are important when precision matters, it is important the consideration of additional diagrams that affect mostly the tW production. There is Diagram Substraction and Diagram Removal Scheme that can be used to estimate the impact of the effect. I was wondering how this DR/DS Scheme can be called when generating events in Madgraph.
Question information
- Language:
- English Edit question
- Status:
- Answered
- Assignee:
- marco zaro Edit question
- Last query:
- Last reply:
|
Revision history for this message
|
#1 |
Hi,
You should use the following PLUGIN:
https:/
(documented here https:/
Cheers,
Olivier
|
Revision history for this message
|
#2 |
Hello I added MadSTR into PLUGIN,
so I did:
./bin/mg5_aMC --mode=MadSTR photo_tW_
with the file containing:
import model sm
define myp = g u d c s b u~ d~ c~ s~ b~
define myt = t t~
define myw = w+ w-
define m_all = w+ w- g u d c s b u~ d~ c~ s~ b~
generate myp myp > myt myw [QCD]
output photo_tW_pp_13TeV
It runs fine. then I simply did (in output directory):
./bin/generate_
and ends with the following error:
INFO: For gauge cancellation, the width of 't' has been set to zero
Error detected in "launch "
write debug file /home/javier/
If you need help with this issue please contact us on https:/
aMCatNLOError : An error occurred during the collection of results.
Please check the .log files inside the directories which failed:
/home/
/home/
/home/
/home/
/home/
/home/
/home/
/home/
The second question is if in case of wanting to use the option set lpp1 2, would it need to be set in the run_card.dat? as I see it is not possible to use that command in the MG5_aMC shell.
The report file that is generated is below.
Thanks
Javier
-------
-------
-------
-------
#******
#* MadGraph5_aMC@NLO *
#* *
#* * * *
#* * * * * *
#* * * * * 5 * * * * *
#* * * * * *
#* * * *
#* *
#* *
#* VERSION 5.2.7.2 20xx-xx-xx *
#* *
#* The MadGraph5_aMC@NLO Development Team - Find us at *
#* https:/
#* and *
#* http://
#* *
#******
#* *
#* Command File for aMCatNLO *
#* *
#* run as ./bin/aMCatNLO.py filename *
#* *
#******
launch cd ..
Traceback (most recent call last):
File "/home/
return self.onecmd_
File "/home/
return func(arg, **opt)
File "/home/
self.
File "/home/
raise self.InvalidCmd, 'Invalid Syntax: Too many argument'
InvalidCmd: Invalid Syntax: Too many argument
Value of current Options:
cluster_
automatic_
exrootana
notificat
#******
#* MadGraph5_aMC@NLO *
#* *
#* * * *
#* * * * * *
#* * * * * 5 * * * * *
#* * * * * *
#* * * *
#* *
#* *
#* VERSION 2.7.2 2020-03-17 *
#* *
#* The MadGraph5_aMC@NLO Development Team - Find us at *
#* https:/
#* *
#******
#* *
#* Command File for MadGraph5_aMC@NLO *
#* *
#* run as ./bin/mg5_aMC filename *
#* *
#******
set default_
set group_subprocesses Auto
set ignore_
set loop_optimized_
set loop_color_flows False
set gauge unitary
set complex_mass_scheme False
set max_npoint_
import model sm
define p = g u c d s u~ c~ d~ s~
define j = g u c d s u~ c~ d~ s~
define l+ = e+ mu+
define l- = e- mu-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~
define myp = g u d c s b u~ d~ c~ s~ b~
define myt = t t~
define myw = w+ w-
define m_all = w+ w- g u d c s b u~ d~ c~ s~ b~
import model loop_sm
generate myp myp > myt myw [QCD]
output photo_tW_pp_13TeV
#######
## PARAM_CARD AUTOMATICALY GENERATED BY MG5 FOLLOWING UFO MODEL ####
#######
## ##
## Width set on Auto will be computed following the information ##
## present in the decay.py files of the model. ##
## See arXiv:1402.1178 for more details. ##
## ##
#######
#######
## INFORMATION FOR LOOP
#######
Block loop
1 9.118800e+01 # MU_R
#######
## INFORMATION FOR MASS
#######
Block mass
5 4.700000e+00 # MB
6 1.730000e+02 # MT
15 1.777000e+00 # MTA
23 9.118800e+01 # MZ
25 1.250000e+02 # MH
## Dependent parameters, given by model restrictions.
## Those values should be edited following the
## analytical expression. MG5 ignores those values
## but they are important for interfacing the output of MG5
## to external program such as Pythia.
1 0.000000e+00 # d : 0.0
2 0.000000e+00 # u : 0.0
3 0.000000e+00 # s : 0.0
4 0.000000e+00 # c : 0.0
11 0.000000e+00 # e- : 0.0
12 0.000000e+00 # ve : 0.0
13 0.000000e+00 # mu- : 0.0
14 0.000000e+00 # vm : 0.0
16 0.000000e+00 # vt : 0.0
21 0.000000e+00 # g : 0.0
22 0.000000e+00 # a : 0.0
24 8.041900e+01 # w+ : cmath.sqrt(
#######
## INFORMATION FOR SMINPUTS
#######
Block sminputs
1 1.325070e+02 # aEWM1
2 1.166390e-05 # Gf
3 1.180000e-01 # aS
#######
## INFORMATION FOR YUKAWA
#######
Block yukawa
5 4.700000e+00 # ymb
6 1.730000e+02 # ymt
15 1.777000e+00 # ymtau
#######
## INFORMATION FOR DECAY
#######
DECAY 6 1.491500e+00 # WT
DECAY 23 2.441404e+00 # WZ
DECAY 24 2.047600e+00 # WW
DECAY 25 6.382339e-03 # WH
## Dependent parameters, given by model restrictions.
## Those values should be edited following the
## analytical expression. MG5 ignores those values
## but they are important for interfacing the output of MG5
## to external program such as Pythia.
DECAY 1 0.000000e+00 # d : 0.0
DECAY 2 0.000000e+00 # u : 0.0
DECAY 3 0.000000e+00 # s : 0.0
DECAY 4 0.000000e+00 # c : 0.0
DECAY 5 0.000000e+00 # b : 0.0
DECAY 11 0.000000e+00 # e- : 0.0
DECAY 12 0.000000e+00 # ve : 0.0
DECAY 13 0.000000e+00 # mu- : 0.0
DECAY 14 0.000000e+00 # vm : 0.0
DECAY 15 0.000000e+00 # ta- : 0.0
DECAY 16 0.000000e+00 # vt : 0.0
DECAY 21 0.000000e+00 # g : 0.0
DECAY 22 0.000000e+00 # a : 0.0
#======
# QUANTUM NUMBERS OF NEW STATE(S) (NON SM PDG CODE)
#======
Block QNUMBERS 82 # gh
1 0 # 3 times electric charge
2 1 # number of spin states (2S+1)
3 8 # colour rep (1: singlet, 3: triplet, 8: octet)
4 1 # Particle/
#******
# MadGraph5_aMC@NLO *
# *
# run_card.dat aMC@NLO *
# *
# This file is used to set the parameters of the run. *
# *
# Some notation/
# *
# Lines starting with a hash (#) are info or comments *
# *
# mind the format: value = variable ! comment *
# *
# Some of the values of variables can be list. These can either be *
# comma or space separated. *
# *
# To display additional parameter, you can use the command: *
# update to_full *
#******
#
#******
# Running parameters
#******
#
#******
# Tag name for the run (one word) *
#******
tag_1 = run_tag ! name of the run
#******
# Number of LHE events (and their normalization) and the required *
# (relative) accuracy on the Xsec. *
# These values are ignored for fixed order runs *
#******
10000 = nevents ! Number of unweighted events requested
-1.0 = req_acc ! Required accuracy (-1=auto determined from nevents)
-1 = nevt_job ! Max number of events per job in event generation.
! (-1= no split).
#******
# Normalize the weights of LHE events such that they sum or average to *
# the total cross section *
#******
average = event_norm ! valid settings: average, sum, bias
#******
# Number of points per itegration channel (ignored for aMC@NLO runs) *
#******
0.01 = req_acc_fo ! Required accuracy (-1=ignored, and use the
# These numbers are ignored except if req_acc_FO is equal to -1
5000 = npoints_fo_grid ! number of points to setup grids
4 = niters_fo_grid ! number of iter. to setup grids
10000 = npoints_fo ! number of points to compute Xsec
6 = niters_fo ! number of iter. to compute Xsec
#******
# Random number seed *
#******
0 = iseed ! rnd seed (0=assigned automatically=
#******
# Collider type and energy *
#******
1 = lpp1 ! beam 1 type (0 = no PDF)
1 = lpp2 ! beam 2 type (0 = no PDF)
6500.0 = ebeam1 ! beam 1 energy in GeV
6500.0 = ebeam2 ! beam 2 energy in GeV
#******
# PDF choice: this automatically fixes also alpha_s(MZ) and its evol. *
#******
nn23nlo = pdlabel ! PDF set
244600 = lhaid ! If pdlabel=lhapdf, this is the lhapdf number. Only
! numbers for central PDF sets are allowed. Can be a list;
! PDF sets beyond the first are included via reweighting.
#******
# Include the NLO Monte Carlo subtr. terms for the following parton *
# shower (HERWIG6 | HERWIGPP | PYTHIA6Q | PYTHIA6PT | PYTHIA8) *
# WARNING: PYTHIA6PT works only for processes without FSR!!!! *
#******
HERWIG6 = parton_shower
1.0 = shower_scale_factor ! multiply default shower starting
#******
# Renormalization and factorization scales *
# (Default functional form for the non-fixed scales is the sum of *
# the transverse masses divided by two of all final state particles *
# and partons. This can be changed in SubProcesses/
# dynamical_
#******
False = fixed_ren_scale ! if .true. use fixed ren scale
False = fixed_fac_scale ! if .true. use fixed fac scale
91.118 = mur_ref_fixed ! fixed ren reference scale
91.118 = muf_ref_fixed ! fixed fact reference scale
-1 = dynamical_
! dynamical choices. Can be a list; scale choices beyond the
! first are included via reweighting
1.0 = mur_over_ref ! ratio of current muR over reference muR
1.0 = muf_over_ref ! ratio of current muF over reference muF
#******
# Reweight variables for scale dependence and PDF uncertainty *
#******
1.0, 2.0, 0.5 = rw_rscale ! muR factors to be included by reweighting
1.0, 2.0, 0.5 = rw_fscale ! muF factors to be included by reweighting
True = reweight_scale ! Reweight to get scale variation using the
! rw_rscale and rw_fscale factors. Should be a list of
! booleans of equal length to dynamical_
! specify for which choice to include scale dependence.
False = reweight_pdf ! Reweight to get PDF uncertainty. Should be a
! list booleans of equal length to lhaid to specify for
! which PDF set to include the uncertainties.
#******
# Store reweight information in the LHE file for off-line model- *
# parameter reweighting at NLO+PS accuracy *
#******
False = store_rwgt_info ! Store info for reweighting in LHE file
#******
# ickkw parameter: *
# 0: No merging *
# 3: FxFx Merging - WARNING! Applies merging only at the hard-event *
# level. After showering an MLM-type merging should be applied as *
# well. See http://
# 4: UNLOPS merging (with pythia8 only). No interface from within *
# MG5_aMC available, but available in Pythia8. *
# -1: NNLL+NLO jet-veto computation. See arxiv:1412.8408 [hep-ph]. *
#******
0 = ickkw
#******
#
#******
# BW cutoff (M+/-bwcutoff*
# written in the LHE event file *
#******
15.0 = bwcutoff
#******
# Cuts on the jets. Jet clustering is performed by FastJet. *
# - When matching to a parton shower, these generation cuts should be *
# considerably softer than the analysis cuts. *
# - More specific cuts can be specified in SubProcesses/cuts.f *
#******
1.0 = jetalgo ! FastJet jet algorithm (1=kT, 0=C/A, -1=anti-kT)
0.7 = jetradius ! The radius parameter for the jet algorithm
10.0 = ptj ! Min jet transverse momentum
-1.0 = etaj ! Max jet abs(pseudo-rap) (a value .lt.0 means no cut)
#******
# Cuts on the charged leptons (e+, e-, mu+, mu-, tau+ and tau-) *
# More specific cuts can be specified in SubProcesses/cuts.f *
#******
0.0 = ptl ! Min lepton transverse momentum
-1.0 = etal ! Max lepton abs(pseudo-rap) (a value .lt.0 means no cut)
0.0 = drll ! Min distance between opposite sign lepton pairs
0.0 = drll_sf ! Min distance between opp. sign same-flavor lepton pairs
0.0 = mll ! Min inv. mass of all opposite sign lepton pairs
30.0 = mll_sf ! Min inv. mass of all opp. sign same-flavor lepton pairs
#******
# Photon-isolation cuts, according to hep-ph/9801442. When ptgmin=0, *
# all the other parameters are ignored. *
# More specific cuts can be specified in SubProcesses/cuts.f *
#******
20.0 = ptgmin ! Min photon transverse momentum
-1.0 = etagamma ! Max photon abs(pseudo-rap)
0.4 = r0gamma ! Radius of isolation code
1.0 = xn ! n parameter of eq.(3.4) in hep-ph/9801442
1.0 = epsgamma ! epsilon_gamma parameter of eq.(3.4) in hep-ph/9801442
True = isoem ! isolate photons from EM energy (photons and leptons)
#******
# Cuts associated to MASSIVE particles identified by their PDG codes. *
# All cuts are applied to both particles and anti-particles, so use *
# POSITIVE PDG CODES only. Example of the syntax is {6 : 100} or *
# {6:100, 25:200} for multiple particles *
#******
{} = pt_min_pdg ! Min pT for a massive particle
{} = pt_max_pdg ! Max pT for a massive particle
{} = mxx_min_pdg ! inv. mass for any pair of (anti)particles
#******
# For aMCfast+APPLGRID use in PDF fitting (http://
#******
0 = iappl ! aMCfast switch (0=OFF, 1=prepare grids, 2=fill grids)
#******
|
Revision history for this message
|
#3 |
Hi Javier,
by default, the 'sm' model has a massive b. For tw you should use the restriction with mb=0
In order to do so, just replace
import model sm
by
import model loop_sm-no_b_mass
in your input file.
Cheers,
Marco
|
Revision history for this message
|
#4 |
Hello Marco Thanks,
The problem was indee resolved by using:
import model sm-no_b_mass
Then I would only keep the second question:
In case of wanting to use set lpp1 = 2 with also MadSTR and [QCD], does one need to set this manually in the run_card?
Cheers
Javier
|
Revision history for this message
|
#5 |
Hi,
The MadSTR plugin does not support the launch command, so you have to run
./bin/generate_
with a separate script or by hand from inside the process directory
If you use the script, then you can also set the parameters of the run_card as usual, otherwise you can edit it by hand
Out of curiosity, why do you want to set lpp1=2?
Best wishes,
Marco
|
Revision history for this message
|
#6 |
Hello Marco,
so I’m testing MadSTR with [QCD]
For the process p p > t W
But I’m interested in
a p > t W
and
a p > ttbar
With lpp1=2
|
Revision history for this message
|
#7 |
Hello Marco,
So it seems that with MadSTR and NLO
a p > tW
with lpp1=2
might not be possible with NLO accuracy as the message I got says (below).
So NLO will not work for those cases? We are trying to generate photo-produced tW and ttbar samples with NLO accuracy and MadSTR different models.
Cheers
Javier
Command "launch " interrupted with error:
InvalidRunCard : Process like Deep Inelastic scattering not supported at NLO accuracy.
Please report this bug on https:/
More information is found in 'ME5_debug'.
Please attach this file to your report.
|
Revision history for this message
|
#8 |
Hi Javier,
I fear it will not work the way you are trying. One thing may be to leave lpp=1 in both cases, and then override the call to the PDFs in order to have the correct photon density
Let me know if you would like to go further in this direction
Cheers,
Marco
|
Revision history for this message
|
#9 |
Hi Javier,
I fear it will not work the way you are trying. One thing may be to leave lpp=1 in both cases, and then override the call to the PDFs in order to have the correct photon density
Let me know if you would like to go further in this direction
Cheers,
Marco
|
Revision history for this message
|
#10 |
Hi Marco,
If you think that such mix mode is working (i.e. no missing/wrong NLO counter-term).
Then the easiest is to bypass the python-level crash. and let the code to run
If the associated elastic PDF is not part of the NLO code, I can also add it that's simple enough.
Cheers,
Olivier
|
Revision history for this message
|
#11 |
Hi Olivier,
I think it may be working. The photon will not split as far as QCD corrections are concerned, so I do not think anything is missing.
It would be safer, though, to check that e.g. for t t~ @NLO one gets the correct result (do other codes exist to compare against?), and then to use DR/DS.
To skip the check, edit madgraph/
if self['lpp1']!=1 or self['lpp2']!=1:
and change it to
if self['lpp1’]==0 or self['lpp2’]==0:
(I fear that other similar warning/crashes are in the code…)
Let me know
cheers,
Marco
> On 9 Jun 2020, at 10:05, Olivier Mattelaer <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Olivier Mattelaer proposed the following answer:
> Hi Marco,
>
> If you think that such mix mode is working (i.e. no missing/wrong NLO counter-term).
> Then the easiest is to bypass the python-level crash. and let the code to run
>
> If the associated elastic PDF is not part of the NLO code, I can also
> add it that's simple enough.
>
> Cheers,
>
> Olivier
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#12 |
Hello Marco, Olivier,
Yes I would like to proceed, this is for a search analysis in pp at 13 TeV.
NLO with DS/DR works with lpp1 = lpp2 =1.
So for the first option you suggest how could I override the call to the PDFs so photon probability is right?
For the other comments I understand the photon could be made not affected by the QCD corrections.
Please let me know if I should test anything.
Many Thanks
Javier
|
Revision history for this message
|
#13 |
Hi Javier,
my question is, do you know of any other code which can compute a reference cross section in photoproduction for a process, (e.g. t tbar?) so that we can use it for comparison? This would help to trust more the results.
Thanks,
Marco
|
Revision history for this message
|
#14 |
Hello Marco,
Let me check if I can find something to guide us. I'm not sure there will much reference at NLO.
An option I can think of is that
I once ran a new feature in pythia that allows gamma-proton interactions I think a configuration was generated providing the photon from the flux of one of the protons and it was able to give a cross-section. Even if it is at LO, it could help. Now this was only possible for ttbar as for some reason attempting with tW was challenging.
I can send you this config tomorrow, or are you interested in the cross-section estimate for pp at 13 TeV for ttbar photoproduction?, I can send you the number it gives too.
Of course what interests us is to have this at NLO and with the DR/DS Madgraph feature with both tW and ttbar.
Thanks
Javier
|
Revision history for this message
|
#15 |
Hello Marco, Olivier,
So for the pythia LO configuration I mentioned (with flux from proton from Drees-Zeppenfeld)
it gives 0.7341 pb
for gamma emitted for one of the protons at 13 TeV to t tbar.
So attempted the same with Madgrah at LO and I see the newer version asks for:
set fixed_scale 500
when set lpp1 2 is called.
if one does not introduce the scale it gives:
"Since 2.7.1 Photon from proton are using fixed scale value of muf [dsqrt_q2fact1] as the cut of th Improved Weizsaecker-
but that makes the cross-section dependent of this scale I tried different values.
What kind of reference cross-section would you need, would you need a higher order calculation from other package?
Thanks
Javier
|
Revision history for this message
|
#16 |
> but that makes the cross-section dependent of this scale I tried different values.
This is nothing new to 2.7.1. That cross-section depends for the cut-off included in that formula (which acts as a scale).
Before 2.7.1, that scale was setting to mu_r=mu_f and could therefore be dynamical which is typically not what is used for such type of formula (and was quite obscur since you had to read a old paper to know that).
The new implementation allows for p a where each of them have their own scale which makes more sense.
Secondly it gives the advantages that the use of such scale is now explicit rather than implicit.
Cheers,
Olivier
|
Revision history for this message
|
#17 |
Hello Olivier, Marco,
I agree,
I'll give a look to
V.M.Budnev et al., Phys.Rep. 15C (1975) 181
to remember the action of this parameter.
beside that I'll try to search for another reference for pp ttbar or tW photoproduction cross section.
So this would be to generate preliminary samples with cms, so we can test sensitivity to signal strenght, but and evaluation of DS and DR effects at NLO are needed.
Many Thanks
Javier
|
Revision history for this message
|
#18 |
Dear Olivier, Marco,
So we are considering starting up the analysis with the LO version. since we can start testing some forward detectors.
The analysis aims to probe the signal strenght of photoproduced ttbar and tW with Run2 pp 13 TeV data.
The initial idea was to have a NLO simulation of this signal so effects like DR/DS effects could be inspected as part of the systematic uncertainty.
Unless the NLO photoproduction of ttbar and tW in pp could be available soon. If not we could start up as above and then try to update.
Please let me know your thoughts.
Thanks
Javier
|
Revision history for this message
|
#19 |
Hi Javier,
I think that
generate a p > t t~ [QCD]
add process p a > t t~ [QCD]
should work at NLO for top pair production. However, it has never been tested against any other computation, so I am not 100% sure that the result is correct. In my opinion, it would be safer to start with LO. If the theoretical uncertainty is too large and it becomes a limiting factor, then we will better investigate how to go NLO
Does this sound reasonable to you?
Cheers,
Marco
> On 7 Jul 2020, at 02:41, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Dear Olivier, Marco,
>
> So we are considering starting up the analysis with the LO version.
> since we can start testing some forward detectors.
>
> The analysis aims to probe the signal strenght of photoproduced ttbar
> and tW with Run2 pp 13 TeV data.
>
> The initial idea was to have a NLO simulation of this signal so effects
> like DR/DS effects could be inspected as part of the systematic
> uncertainty.
>
> Unless the NLO photoproduction of ttbar and tW in pp could be available
> soon. If not we could start up as above and then try to update.
>
> Please let me know your thoughts.
>
> Thanks
>
> Javier
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#20 |
Hello Marco,
Yes I can propose this. I think we can start with LO but compare with the number it gives at NLO too.
I'll do some checks and write back.
Many Thanks
Javier
|
Revision history for this message
|
#21 |
Hello Marco,
*** At LO I attempted the following that works:
generate a myp > t t~
set lpp1 2
set fixed_scale 300
set ebeam1 6500
set ebeam2 6500
using the lpp1 change to elastic.
*** For NLO I attempt the following:
generate a myp > t t~ [QCD]
##set lpp1 2
set fixed_scale 300
set ebeam1 6500
set ebeam2 6500
without changing lpp1 to elastic, otherwise it crashes. So I remember you mentioned for the NLO case to leave the two lpp's into 1 and then you something about overriding the call of the PDF's, how can this be done?
I add my results for cross-section values for LO and NLO cases here:
https:/
Please let me know what could be the best way to proceed, since NLO cross-section is differing by a lot from the LO one. And also I'm letting the two lpp's to 1, so the elasticity associated with the photon is not stated.
As a first step I wanted to compare these two scenarios and their sensitivity to the "fixed_scale".
Thanks
Javier
|
Revision history for this message
|
#22 |
Hi Javier,
so, I tried
generate p a > t t~ [QCD]
with the default (Ht/2) dynamic scale
and I get 3.15 pb at NLO, and 2.57 at LO. Numbers and the code seem
reasonable.
Now, the large difference between your LO and NLO run is certainly due to
the fact that at LO you use the (correct) elastic photon parameterization,
while in the NLO code you use the photon from NNPDF2.3. So you are not
comparing apples with apples.
Now, in order to have the code working also at NLO, you need to override
the call to the photon PDF and insert there the elastic parameterization.
In particular, the pdf calls are wrapped inside
Source/
what you have to do is to override the call to the pdf routine at the end
of the pdg2pdf subroutine (pdftopdg without lhapdf, evolvepartm with
lhapdf6) if ipart=7, which is the photon. Leave the rest untouched, as
there is some caching which is performed. You can send the changes to me
for a cross check.
Best wishes,
Marco
Marco Zaro
On Thu, Jul 16, 2020 at 3:50 AM Javier <email address hidden>
wrote:
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Hello Marco,
>
> *** At LO I attempted the following that works:
>
> generate a myp > t t~
> set lpp1 2
> set fixed_scale 300
> set ebeam1 6500
> set ebeam2 6500
>
> using the lpp1 change to elastic.
>
> *** For NLO I attempt the following:
>
> generate a myp > t t~ [QCD]
> ##set lpp1 2
> set fixed_scale 300
> set ebeam1 6500
> set ebeam2 6500
>
> without changing lpp1 to elastic, otherwise it crashes. So I remember
> you mentioned for the NLO case to leave the two lpp's into 1 and then
> you something about overriding the call of the PDF's, how can this be
> done?
>
> I add my results for cross-section values for LO and NLO cases here:
>
>
> https:/
>
> Please let me know what could be the best way to proceed, since NLO
> cross-section is differing by a lot from the LO one. And also I'm
> letting the two lpp's to 1, so the elasticity associated with the photon
> is not stated.
>
> As a first step I wanted to compare these two scenarios and their
> sensitivity to the "fixed_scale".
>
> Thanks
>
> Javier
>
> --
> You received this question notification because you are subscribed to
> the question.
>
|
Revision history for this message
|
#23 |
Dear Marco;
I could not run the LO without giving a value to ‘fixed_scale’, otherwise it crashes, this is the most recent version. If you got 2.57pb I assume it had a very small value. How can I set it to run the default value in LO so I reproduce your number?
Yes I can reproduce your NLO initial test without moving ‘fixed_scale’. With 100k events I get:
import model sm-no_b_mass
generate p a > t t~ [QCD]
-------
Summary:
Process p a > t t~ [QCD]
Run at p-p collider (6500.0 + 6500.0 GeV)
Number of events generated: 100000
Total cross section: 3.164e+00 +- 9.9e-03 pb
----
Scale variation (computed from LHE events):
----
I assume the bottom is some sort of systematic associated with the scale, but I see it is called different not ‘fixed_scale’ but ‘Dynamical_
So I tried modifying pdg2pdf.f, pdg2pdf_lhapdf.f and pdg2pdf_lhapdf6.f. Only the first one had an effect so assume that is the one that is being used. So for that one I do
if(iabs(
call pftopdg(
But it crashes. I assume this is the call you mean. It says it is an expected end for this file. I added similar lines to the other two files.
I can work on any suggestion to complete this step.
Many Thanks
Javier
|
Revision history for this message
|
#24 |
Hi Javier
> On 31 Jul 2020, at 05:55, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Dear Marco;
>
> I could not run the LO without giving a value to ‘fixed_scale’,
> otherwise it crashes, this is the most recent version. If you got 2.57pb
> I assume it had a very small value. How can I set it to run the default
> value in LO so I reproduce your number?
>
> Yes I can reproduce your NLO initial test without moving ‘fixed_scale’.
> With 100k events I get:
>
> import model sm-no_b_mass
> generate p a > t t~ [QCD]
> -------
> Summary:
> Process p a > t t~ [QCD]
> Run at p-p collider (6500.0 + 6500.0 GeV)
> Number of events generated: 100000
> Total cross section: 3.164e+00 +- 9.9e-03 pb
> -------
> Scale variation (computed from LHE events):
> Dynamical_
> 3.175e+00 pb +9.1% -9.7%
> ———————
but within the NLO code, you can select order=LO at the beginning of the run. This is how I produced the LO xsection
>
> I assume the bottom is some sort of systematic associated with the
> scale, but I see it is called different not ‘fixed_scale’ but
> ‘Dynamical_
> ~3.17 and not as above ~3.16. They get closer with more events actually.
>
> So I tried modifying pdg2pdf.f, pdg2pdf_lhapdf.f and pdg2pdf_lhapdf6.f.
> Only the first one had an effect so assume that is the one that is being
> used. So for that one I do
>
> if(iabs(
> call pftopdg(
>
> But it crashes. I assume this is the call you mean. It says it is an
> expected end for this file. I added similar lines to the other two
> files.
>
It is likely a compilation error.
Are you missing an else/endif? can you go into any of the P0 folders and compile
make madevent_mintFO
and paste the specific error you get?
Thanks!
cheers,
Marco
> I can work on any suggestion to complete this step.
>
> Many Thanks
>
> Javier
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#25 |
Dear Marco
the compilation error was indeed a missing endif.
I currently add:
if(iabs(
call pftopdg(
endif
into pdg2pdf.f
it then at NLO gives (with 100k events):
generate p a > t t~ [QCD]
-------
----
Summary:
Process p a > t t~ [QCD]
Run at p-p collider (6500.0 + 6500.0 GeV)
Number of events generated: 100000
Total cross section: 3.647e+03 +- 1.3e+02 pb
----
Scale variation (computed from LHE events):
----
It seems to be then dependent on the 'Dynamical_
I saw a huge improvement in precision from 10k to 100k events. I can try to see what is the value for 1M. I assume we want to compare with the 2.57pb we see at LO.
So please let me know if this is as expected. and I'll try to get a more accurate value for this correction, for reason it needs much more events for higher precision.
Thanks
Javier
|
Revision history for this message
|
#26 |
Hi Javier,
I am not sure to understand
> On 6 Aug 2020, at 10:05, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Dear Marco
>
> the compilation error was indeed a missing endif.
>
> I currently add:
>
> if(iabs(
> call pftopdg(
> endif
>
> into pdg2pdf.f
what do you do instead if ipart=7, ie in the case of the photon?
>
> it then at NLO gives (with 100k events):
>
> generate p a > t t~ [QCD]
> -------
> -------
> Summary:
> Process p a > t t~ [QCD]
> Run at p-p collider (6500.0 + 6500.0 GeV)
> Number of events generated: 100000
> Total cross section: 3.647e+03 +- 1.3e+02 pb
> -------
> Scale variation (computed from LHE events):
> Dynamical_
> 1.363e+05 pb +46.1% -45.1%
> -------
> It seems to be then dependent on the 'Dynamical_
Because here I would expect the two numbers to be compatible within stat errors…
So I suspect that something is not working properly
cheers,
marco
>
> I saw a huge improvement in precision from 10k to 100k events. I can try
> to see what is the value for 1M. I assume we want to compare with the
> 2.57pb we see at LO.
>
> So please let me know if this is as expected. and I'll try to get a more
> accurate value for this correction, for reason it needs much more events
> for higher precision.
>
> Thanks
>
> Javier
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#27 |
Hello Marco,
so what I understood is that for the case of the photon we wanted to override this call without modifying anything else.
I think what is missing is inserting the elastic parametrization when it is the photon. where can I find this bit of code so I can insert it at the end of pdg2pdf.f ?
I'll be checking
Thanks
Javier
|
Revision history for this message
|
#28 |
Hi Javier,
yes, so you must override the call in order to have sensible results.
I don't really know where to find it, try looking into Template/
Best wishes,
Marco
|
Revision history for this message
|
#29 |
Dear Marco,
I checked the flux from proton in PhotonFlux.f which has the formula for photon energy spectrum.
So was thinking in something like:
-------
if(
.... ELASTIC PARAMETRIZATION ...
else ! USUAL CALL
call pftopdg(
endif
-------
So the elastic parametrization only happens when ih ==2 (proton without breaking) and ipar==7 (photon).
though, I realized there are some lines just above this call in pdg2pdf.f with the following:
-------
if(
elseif(ih .eq. 2) then !from a proton without breaking
endif
return
endif
-------
Which I think already calls for the epa_proton for the case we need and puts in pdg2pdf. This why I'm not sure if calling pftopdg() for the case of the photon at the end of this file is still necessary.
If it is called, I also see in the definition of pftopdg(ih,x,q,pdf) that if ih is 2 then it gives fx(7) the epa_proton.
I'm still checking but any guidance would help.
Thanks
Javier
|
Revision history for this message
|
#30 |
Hi Javier,
Indeed the call to epa_proton is already supported for NLO computation.
Now this is is certainly a quite hidden support so one need to be very careful about the physical meaning and check everything carefully. (I doubt that any MG5aMC authors have tested this mode/validated it, it is more likely due to a copy/paste from some LO template that such code is included)
This being said:
1) The implemention works only if you do not set "pdlabel" to lhapdf (so for your mix case, this is strong constrain on the PDF that you can use). If you want to use another PDF for the second beam, then you will need to edit the file pdg2pdf_lhapdf.f or pdg2pdf_lhapdf6.f
2) The support at NLO is not exactly the same as the one at LO concerning the scale choice (at LO, we are always using a fix scale computation for the EPA, while @NLO, we still have the old behavior (that the scale of both beam are the same --and by default dynamical--)
I'm not sure that this really answer your question bout EPA. Does it?
Cheers,
Olivier
|
Revision history for this message
|
#31 |
Hello Olivier,
Thanks.
So in this case (NLO) the 'pdflabel' is not set to 'lhapdf', which is verified by only having effect in the XS calculation when modifiying pdg2pdf.f
So then the epa_proton is being implemented already. I add below the comparison then between LO and NLO.
So the precision for 'Total cross-section' is enough to exclude the two results from each other, but then not clear when considering the variation of the 'Dynamical_
So I guess the main issue was to identify what is the cause of this difference below, and initially it was thought that it was because the proton EPA was not used for NLO but the proton PDF instead. But with what you say it is not the case (and for what is is in pdg2pdf.f). Though the difference could be arising from the treatment of the scale you mention, and then the question would be how can we put these two in the same terms, for example using at NLO same strategy as LO? The attention over NLO at the beginning is due to the interest of having a production of this process at NLO as other top analyses.
**** LO (Process p a > t t~)
-------
Summary:
Process p a > t t~
Run at p-p collider (6500.0 + 6500.0 GeV)
Number of events generated: 500000
Total cross section: 2.578e+00 +- 3.6e-03 pb
----
Scale variation (computed from LHE events):
----
**** NLO (Process p a > t t~ [QCD])
-----
Summary:
Process p a > t t~ [QCD]
Run at p-p collider (6500.0 + 6500.0 GeV)
Number of events generated: 500000
Total cross section: 3.182e+00 +- 5.2e-03 pb
----
Scale variation (computed from LHE events):
----
|
Revision history for this message
|
#32 |
Hi Javier,
are you sure that the numbers you get are with an elastic photon parameterization?
I got very similar numbers
3.15 pb at NLO, and 2.57 at LO.
without touching the code, so using the photon as from the default pdf set (nnpdf 2.3 qed)
Best wihes,
marco
|
Revision history for this message
|
#33 |
Hi,
I agree with Marco.
if I run:
generate p a > t t~
output
launch
launch
set lpp2 2
I got:
elastic+
elastic: 0.5862
Note that The systematic computations crashes in the case of elastic only
Doing the same at NLO:
generate p a > t t~ [QCD]
output
launch
launch
set lpp2 2
I got
elastic+
elastic: 6.968e-01
In this case both pass for the computation of the systematics but i had to remove a crash that prevent the code to run with lpp2=2
Cheers,
Olivier
|
Revision history for this message
|
#34 |
Hello Marco and Olivier,
I think then I'm in a middle of a confusion now.
So, from the previous messages from yesterday I though we confirm that the epa_proton is currently being implemented at NLO. Which I can see in the pdg2pdf.f file (I dont use the 'lhapdf' label).
So should this not take into account the elastic effect? as this epa_proton takes already the 'Weizsaecker-
But from what you say there seems something is still missing. By the way I haven't basically done anything as I think the 'call' at the end of pdg2pdf.f should already take into acount the parametrization for initial photon(7) and proton (2) with no break and there was a condition already that replaces the pdf.
this is in the piece of code below, before the call:
if(
elseif(ih .eq. 2) then !from a proton without breaking
endif
return
endif
|
Revision history for this message
|
#35 |
I guess that the confusion is on the value of ih.
"ih" is the fortran variable that correspond to the entry
lpp1 (or lpp2) from the run_card.
So if you want to use that elastic mode, you need to set lpp1 (or lpp2 or both) to 2.
If you keep lpp1 to 1, then you will use the normal PDF which in the case of NNPDF includes both elastic and inelastic contribution (other PDF can only include inelatic contribution).
Is it more clear now?
Cheers,
Olivier
> On 19 Aug 2020, at 20:45, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Hello Marco and Olivier,
>
> I think then I'm in a middle of a confusion now.
>
> So, from the previous messages from yesterday I though we confirm that
> the epa_proton is currently being implemented at NLO. Which I can see in
> the pdg2pdf.f file (I dont use the 'lhapdf' label).
>
> So should this not take into account the elastic effect? as this
> epa_proton takes already the 'Weizsaecker-
> PhotonFlux.f.
>
> But from what you say there seems something is still missing. By the way
> I haven't basically done anything as I think the 'call' at the end of
> pdg2pdf.f should already take into acount the parametrization for
> initial photon(7) and proton (2) with no break and there was a condition
> already that replaces the pdf.
>
> this is in the piece of code below, before the call:
>
> if(iabs(
> q2max=xmu*xmu
> if(ih.eq.3) then !from the electron
> pdg2pdf=
> elseif(ih .eq. 2) then !from a proton without breaking
> pdg2pdf=
> endif
> pdflast(
> return
> endif
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
|
Revision history for this message
|
#36 |
Hello Olivier,
yes. Let me then make some tests before replying.
Thanks
Javier
|
Revision history for this message
|
#37 |
Hello Olivier,
so I include two points with respect this process below considering how the discussion above progressed and your previous answer.
generate p a > t t~ [QCD]
*** 1) At NLO since the beginning we commented that is not possible to run with "lpp2 2" avoiding a crash.
"InvalidRunCard : Process like Deep Inelastic scattering not supported at NLO accuracy"
So the initial plan was to run without the "lpp2 2" and then in the directory somehow override the call of the PDF of the second hadron, so it calls the "epa_proton" instead for that hadron. If lpp2 = 1 (not elastic) it indeed gives a cross section about:
3.16pb
But you mention it is possible to include the lpp2 2 without crash? (though not sure if that helps, as I see a number of cross-section of 3.17pb from your earlier message, which is same as using proton PDF). So yes I understand lpp2 should be in 2 but it is by the default not supported. So if you know how to allow the lpp2 set to elastic at NLO then I can try it.
*** 2) Attempting to override the call of the hadron PDF. So I focuss on "pdg2pdf.f" as I see effects on changes there.
So the epa_proton is ignored for second hadron because "lpp2" is not set to "2" (as explained above). So I attempted to change the condition so it uses the epa_proton when iabs(ipart).eq.7, code looks like below. So in this case I know for one of the hadrons (the second) the ipart is 7 and I don;t ask for lpp2 == 2 as condition to use "epa_proton". But this does not seem to work, as it generates a cross section about:
Total cross section: 6.907e-01 +- 4.1e-03 pb
lower than the LO 2.58pb value. So one thing that could work is if rather than knowing the "ih" or "ipart" numbers, how could I access the order of the hadrons? like hadron 1 and hadron 2, where I know Hadron 2 should be the elastic. As the condition as it is could be affecting the other hadron too.
-------
c if(iabs(
if(
c if(ih.eq.3) then !from the electron
c pdg2pdf=
c elseif(ih .eq. 2) then !from a proton without breaking
c endif
return
endif
-------
|
Revision history for this message
|
#38 |
Hello Olivier and Marco,
So added to my message above, the numbers of XS we have talked about ~3.15pb (NLO) and ~2.57pb (LO) were generated by simply doing p a > t t~ [QCD] and selecting respectivelly order = LO or NLO. but it has never been stated that the photon is produced elasticly or either order option.
So my point is that the source of the LO and NLO discrepancy does not seem have to do with the parametrization right?
and also this makes sense because the XS for photoproducced ttbar should be smaller than one, according to previous calculations I did at LO with a previous MG version.
So I tested the modified code I mention in the asnwer above to force the use of "epa_proton" when the "ipart" is a photon, which is the case here for one of the hadrons. Again I see the LO and NLO discrepancy but I don't think this would have to do with the parametrization.
LO:
-------
Summary:
Process p a > t t~ [QCD]
Run at p-p collider (6500.0 + 6500.0 GeV)
Number of events generated: 10000
Total cross section: 5.677e-01 +- 3.2e-03 pb
----
Scale variation (computed from LHE events):
----
NLO:
----
Summary:
Process p a > t t~ [QCD]
Run at p-p collider (6500.0 + 6500.0 GeV)
Number of events generated: 10000
Total cross section: 6.891e-01 +- 5.2e-03 pb
----
Scale variation (computed from LHE events):
----
|
Revision history for this message
|
#39 |
Hi Javier,
> So added to my message above, the numbers of XS we have talked about ~3.15pb (NLO) and ~2.57pb (LO) were generated by simply doing p a > t t~ [QCD] and selecting respectivelly order = LO or NLO. but it has never been stated that the photon is produced elasticly or either order option.
This choice is implicit with the PDF set that you select. Since each PDF group defines the photon PDF in a different way. So when you have lpp=1 in the run_card and choose a PDF set that choice is done by the PDF set. If you set lpp=2 then you have only elastic photon from the (improved) EPA approximation.
Indeed at NLO, lpp=2 is not officially supported (because it was never validated) but instead of hacking the fortran code to make it work, the easiest is to bypass the crash:
=== modified file 'madgraph/
--- madgraph/
+++ madgraph/
@@ -4072,8 +4072,8 @@
# for lepton-lepton collisions, ignore 'pdlabel' and 'lhaid'
if abs(self[
- if self['lpp1'] == 1 or self['lpp2']==1:
- raise InvalidRunCard(
+ #if self['lpp1'] == 1 or self['lpp2']==1:
+ # raise InvalidRunCard(
if self['pdlabel'
> So my point is that the source of the LO and NLO discrepancy does not seem have to do with the parametrization right?
Which dicrepancy?
Cross-section at LO and NLO are obviously different. In this case it seems that the NLO cross-section is not within the expected error band from the LO one but you have to remember that the theoretical band is not a confidence level band. This is a "rule of thumb" to estimated higher order effect. Some very famous process (including Higgs production) have the same behavior between the LO prediction and the NLO one. So I will not worry about that.
Cheers,
Olivier
|
Revision history for this message
|
#40 |
Dear Olivier,
Thanks for that clarification.
So after the update in the banner.py I now run:
generate p a > t t~ [QCD]
set automatic_
output photo_ttbar_
launch
launch
set lpp2 2
and it indeed generates as you can see below the sort of cross-section magnitudes I showed in the previous message.
Also they are indeed different (NLO and LO), but I as well think they don't need to be included with each other as as you say this is not a confidence band as for a measurement vs theory.
So I'll do a preliminar production at NLO. A new detector forward was activated, so this study has great interest.
One thing I'm interested is how can we validate the NLO XS output? How was it done with LO?
Another thing to see is if the DR/DS corrections can be tested as I originally started this thread. So this somehting I can try and report here if I succeed, since this was thought as a systematic effect.
NLO:
----
Summary:
Process p a > t t~ [QCD]
Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
Number of events generated: 10000
Total cross section: 6.968e-01 +- 4.5e-03 pb
----
Scale variation (computed from LHE events):
----
LO:
----
Summary:
Process p a > t t~ [QCD]
Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
Number of events generated: 10000
Total cross section: 5.640e-01 +- 3.1e-03 pb
----
Scale variation (computed from LHE events):
----
|
Revision history for this message
|
#41 |
I do not know how this one was validated at LO (it was validated just before I started my PhD).
I have just validated the LO equivalent for the muon beam.
In that case we vary the scale of the computation and check that the sum of the computation
is stable. (i.e. the sum of elastic photon in collinear regime and the sum of elastic photon outside of the collinear regime). The same should be possible for proton at LO (but you would likely need a specific UFO model since the proton is not a fundamental particle.
Doing the same validation at NLO should be possible I guess.
Cheers,
Olivier
> On 2 Sep 2020, at 08:55, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Dear Olivier,
>
> Thanks for that clarification.
>
> So after the update in the banner.py I now run:
>
> generate p a > t t~ [QCD]
> set automatic_
> output photo_ttbar_
> launch
> launch
> set lpp2 2
>
> and it indeed generates as you can see below the sort of cross-section
> magnitudes I showed in the previous message.
>
> Also they are indeed different (NLO and LO), but I as well think they
> don't need to be included with each other as as you say this is not a
> confidence band as for a measurement vs theory.
>
> So I'll do a preliminar production at NLO. A new detector forward was
> activated, so this study has great interest.
>
> One thing I'm interested is how can we validate the NLO XS output? How
> was it done with LO?
>
> Another thing to see is if the DR/DS corrections can be tested as I
> originally started this thread. So this somehting I can try and report
> here if I succeed, since this was thought as a systematic effect.
>
> NLO:
> -------
> Summary:
> Process p a > t t~ [QCD]
> Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
> Number of events generated: 10000
> Total cross section: 6.968e-01 +- 4.5e-03 pb
> -------
> Scale variation (computed from LHE events):
> Dynamical_
> 7.021e-01 pb +4.4% -5.0%
> -------
>
> LO:
> -------
> Summary:
> Process p a > t t~ [QCD]
> Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
> Number of events generated: 10000
> Total cross section: 5.640e-01 +- 3.1e-03 pb
> -------
> Scale variation (computed from LHE events):
> Dynamical_
> 5.640e-01 pb +11.8% -10.4%
> -------
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
|
Revision history for this message
|
#42 |
Thanks Olivier I also ran over tW as
import model sm-no_b_mass
define myw = w+ w-
generate p a > t myw [QCD]
add process p a > t~ myw [QCD]
set lpp2 2
By the way I came with maybe a silly question. Under this covention beam 2 moves to the right or left?
As I did these preliminar plots for photoproduced ttbar and tW (as can be seen in the link below) and I see that the top effectivelly goes forward but it should be on the side of the beam that delivers the photon based in other studies we have done. So this would seem like the a photon above corresponds to a beam moving in the negative direction.
https:/
By an UFO model you mean something like 'sm-no_b_mass' above? at least for tW is uses the b rather than the proton, though it is taking sometime to get the cross-section. How could I change the scale of the computation to test this?
Thanks
Javier
|
Revision history for this message
|
#43 |
Hi Javier,
are you using madSTR for tw production?
Otherwise, the cross section that you may get after long time is just unphysical…
Cheers,
Marco
> On 3 Sep 2020, at 07:25, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Thanks Olivier I also ran over tW as
>
> import model sm-no_b_mass
> define myw = w+ w-
> generate p a > t myw [QCD]
> add process p a > t~ myw [QCD]
> set lpp2 2
>
> By the way I came with maybe a silly question. Under this covention beam
> 2 moves to the right or left?
>
> As I did these preliminar plots for photoproduced ttbar and tW (as can
> be seen in the link below) and I see that the top effectivelly goes
> forward but it should be on the side of the beam that delivers the
> photon based in other studies we have done. So this would seem like the
> a photon above corresponds to a beam moving in the negative direction.
>
> https:/
> txOicBzjMwjhvtY
>
> By an UFO model you mean something like 'sm-no_b_mass' above? at least
> for tW is uses the b rather than the proton, though it is taking
> sometime to get the cross-section. How could I change the scale of the
> computation to test this?
>
> Thanks
>
> Javier
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#44 |
Hi,
> So this would seem like the
> a photon above corresponds to a beam moving in the negative direction.
That's correct:
beam1 is positive z direction and beam2 negative z direction
> By an UFO model you mean something like 'sm-no_b_mass' above?
Yes that should include the proton as a fundamental particle (only QED interaction should be enough)
such that you can compuute within MG5aMC
generate proton p > proton t t~
where you put a minimum pt cut on the proton
and then vary the pt cut and check that this is compensated by
generate a p > t t~
according to the scale choice
Cheers,
Olivier
> On 3 Sep 2020, at 07:25, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Thanks Olivier I also ran over tW as
>
> import model sm-no_b_mass
> define myw = w+ w-
> generate p a > t myw [QCD]
> add process p a > t~ myw [QCD]
> set lpp2 2
>
> By the way I came with maybe a silly question. Under this covention beam
> 2 moves to the right or left?
>
> As I did these preliminar plots for photoproduced ttbar and tW (as can
> be seen in the link below) and I see that the top effectivelly goes
> forward but it should be on the side of the beam that delivers the
> photon based in other studies we have done. So this would seem like the
> a photon above corresponds to a beam moving in the negative direction.
>
> https:/
> txOicBzjMwjhvtY
>
> By an UFO model you mean something like 'sm-no_b_mass' above? at least
> for tW is uses the b rather than the proton, though it is taking
> sometime to get the cross-section. How could I change the scale of the
> computation to test this?
>
> Thanks
>
> Javier
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
|
Revision history for this message
|
#45 |
Hello Marco,
Actually for tW without 'madSTR' it does not progress in calculating the XS at NLO, it never finishes.
So I then run with madSTR
had to set lpp2=2 in the run card afterwards and it works.
The only question here then is what is the difference between not using madSTR and its default mode, I assume it is a correction that goes beyond NLO right?
I summarize the cross-section it gives below. A bit higher than the LO one which was like 0.49, so this NLO number for tW looks right.
One detail is that the cross-section below has the message: "Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)"
which is right,
but then it shows a message like:
""Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)""
I assume it refers to the elastic proton, since the XS is in the order of the previous LO calculation I did months ago and seems right.
-------
Summary:
Process p a > myt myw [QCD]
Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
Number of events generated: 10000
Total cross section: 5.022e-01 +- 3.7e-03 pb
----
Scale variation (computed from LHE events):
----
|
Revision history for this message
|
#46 |
Hi Javier,
> On 4 Sep 2020, at 10:05, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Hello Marco,
>
> Actually for tW without 'madSTR' it does not progress in calculating the
> XS at NLO, it never finishes.
That is expected, because you have a resonant top quark with zero width, hence a divergence
>
> So I then run with madSTR
>
> had to set lpp2=2 in the run card afterwards and it works.
>
> The only question here then is what is the difference between not using
> madSTR and its default mode, I assume it is a correction that goes
> beyond NLO right?
well, no, actually MadSTR removes the divergence I mentioned above
>
> I summarize the cross-section it gives below. A bit higher than the LO
> one which was like 0.49, so this NLO number for tW looks right.
>
> One detail is that the cross-section below has the message: "Run at
> p-elastic photon from p collider (6500.0 + 6500.0 GeV)"
>
> which is right,
>
> but then it shows a message like:
>
> ""Lepton-lepton collisions: ignoring PDF related parameters in the
> run_card.dat (pdlabel, lhaid, reweight_pdf, ...)”"
hm, I did not find this message, and indeed it is strange (though, it only prevents you to use LHAPDF for the proton PDFs)
Let me know
Cheers,
marco
>
> I assume it refers to the elastic proton, since the XS is in the order
> of the previous LO calculation I did months ago and seems right.
>
> -------
> Summary:
> Process p a > myt myw [QCD]
> Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
> Number of events generated: 10000
> Total cross section: 5.022e-01 +- 3.7e-03 pb
> -------
> Scale variation (computed from LHE events):
> Dynamical_
> 5.126e-01 pb +2.7% -2.6%
> -------
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#47 |
Hello Olivier and Marco,
I installed the newest version of MG and it runs fine with python 3.
The only thing I found is that ONLY when changing the shower name to "PYTHIA8", it shows the error below.
If I dont change the shower it runs fine. Also it runs if I chose shower=OFF or any other option. Also I made sure pythia8 is installed.
wouldn't this have to do with the updates on python?
Cheers
Javier
launch
Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
| 3. Shower the generated events | shower = HERWIG6 | OFF|PYTHIA6Q|
| 4. Decay onshell particles | madspin = OFF | ON|onshell |
| 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
| 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'order=LO' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]
>shower=PYTHIA8
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
| 3. Shower the generated events | shower = PYTHIA8 | HERWIG6|
| 4. Decay onshell particles | madspin = OFF | ON|onshell |
| 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
| 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'order=LO' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.
>
INFO: will run in mode: aMC@NLO
Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
INFO: modify parameter parton_shower of the run_card.dat to PYTHIA8
Do you want to edit a card (press enter to bypass editing)?
/------
| 1. param : param_card.dat |
| 2. run : run_card.dat |
| 3. shower : shower_card.dat |
\------
you can also
- enter the path to a valid card or banner.
- use the 'set' command to modify a parameter directly.
The set option works only for param_card and run_card.
Type 'help set' for more information on this command.
- call an external program (ASperGE/
Type 'help' for the list of available command
[0, done, 1, param, 2, run, 3, shower, enter path][90s to answer]
>
Command "launch " interrupted with error:
TypeError : a bytes-like object is required, not 'str'
Please report this bug on https:/
More information is found in 'ME5_debug'.
Please attach this file to your report.
quit
INFO:
|
Revision history for this message
|
#48 |
Hi Javier,
strange error, what is inside ME5_debug?
Thanks
Marco
> On 9 Sep 2020, at 11:20, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Hello Olivier and Marco,
>
> I installed the newest version of MG and it runs fine with python 3.
>
> The only thing I found is that ONLY when changing the shower name to
> "PYTHIA8", it shows the error below.
>
> If I dont change the shower it runs fine. Also it runs if I chose
> shower=OFF or any other option. Also I made sure pythia8 is installed.
>
> wouldn't this have to do with the updates on python?
>
> Cheers
>
> Javier
>
> launch
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = HERWIG6 | OFF|PYTHIA6Q|
> | 4. Decay onshell particles | madspin = OFF | ON|onshell |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'order=LO' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]
>
>> shower=PYTHIA8
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = PYTHIA8 | HERWIG6|
> | 4. Decay onshell particles | madspin = OFF | ON|onshell |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'order=LO' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.
>>
> INFO: will run in mode: aMC@NLO
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> INFO: modify parameter parton_shower of the run_card.dat to PYTHIA8
> Do you want to edit a card (press enter to bypass editing)?
> /------
> | 1. param : param_card.dat |
> | 2. run : run_card.dat |
> | 3. shower : shower_card.dat |
> \------
> you can also
> - enter the path to a valid card or banner.
> - use the 'set' command to modify a parameter directly.
> The set option works only for param_card and run_card.
> Type 'help set' for more information on this command.
> - call an external program (ASperGE/
> Type 'help' for the list of available command
> [0, done, 1, param, 2, run, 3, shower, enter path][90s to answer]
>>
> Command "launch " interrupted with error:
> TypeError : a bytes-like object is required, not 'str'
> Please report this bug on https:/
> More information is found in 'ME5_debug'.
> Please attach this file to your report.
> quit
> INFO:
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#49 |
Please open a bug report for that and attach the debug file
this has two advantages
- keep one topic per thread (better for readibility)
- bugs report can have attachment (questions can not)
Cheers,
Olivier
> On 9 Sep 2020, at 11:20, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Hello Olivier and Marco,
>
> I installed the newest version of MG and it runs fine with python 3.
>
> The only thing I found is that ONLY when changing the shower name to
> "PYTHIA8", it shows the error below.
>
> If I dont change the shower it runs fine. Also it runs if I chose
> shower=OFF or any other option. Also I made sure pythia8 is installed.
>
> wouldn't this have to do with the updates on python?
>
> Cheers
>
> Javier
>
> launch
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = HERWIG6 | OFF|PYTHIA6Q|
> | 4. Decay onshell particles | madspin = OFF | ON|onshell |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'order=LO' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]
>
>> shower=PYTHIA8
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = PYTHIA8 | HERWIG6|
> | 4. Decay onshell particles | madspin = OFF | ON|onshell |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'order=LO' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.
>>
> INFO: will run in mode: aMC@NLO
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> INFO: modify parameter parton_shower of the run_card.dat to PYTHIA8
> Do you want to edit a card (press enter to bypass editing)?
> /------
> | 1. param : param_card.dat |
> | 2. run : run_card.dat |
> | 3. shower : shower_card.dat |
> \------
> you can also
> - enter the path to a valid card or banner.
> - use the 'set' command to modify a parameter directly.
> The set option works only for param_card and run_card.
> Type 'help set' for more information on this command.
> - call an external program (ASperGE/
> Type 'help' for the list of available command
> [0, done, 1, param, 2, run, 3, shower, enter path][90s to answer]
>>
> Command "launch " interrupted with error:
> TypeError : a bytes-like object is required, not 'str'
> Please report this bug on https:/
> More information is found in 'ME5_debug'.
> Please attach this file to your report.
> quit
> INFO:
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
|
Revision history for this message
|
#50 |
Dear Marco,
I noticed that when doing the production with --mode=MadSTR with tW it makes the options below appear in the run_card.dat, but not if I generate with ttbar. Is it cause it would not make sense for ttbar?
Cheers
Javier
#******
# Parameters relevant for the MasSTR plugin: *
# iSTR controls the strategy for the resonance treatment *
# istr = 1 -> DR without interferece *
# istr = 2 -> DR with interferece *
# istr = 3 -> DS with reshuffling on initial state, standard BW *
# istr = 4 -> DS with reshuffling on initial state, running BW *
# istr = 5 -> DS with reshuffling on all FS particles, standard BW *
# istr = 6 -> DS with reshuffling on all FS particles, running BW *
#******
1 = istr ! strategy to be used to remove resonances
|
Revision history for this message
|
#51 |
Hi Javier,
you do not need to remove resonances for ttbar production, but you do for tw. I guess you (correctly) do not use —mode=MadSTR for ttbar, do you?
Best,
MarcoÎ
> On 21 Sep 2020, at 09:45, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Dear Marco,
>
> I noticed that when doing the production with --mode=MadSTR with tW it
> makes the options below appear in the run_card.dat, but not if I
> generate with ttbar. Is it cause it would not make sense for ttbar?
>
> Cheers
>
> Javier
>
> #******
> # Parameters relevant for the MasSTR plugin: *
> # iSTR controls the strategy for the resonance treatment *
> # istr = 1 -> DR without interferece *
> # istr = 2 -> DR with interferece *
> # istr = 3 -> DS with reshuffling on initial state, standard BW *
> # istr = 4 -> DS with reshuffling on initial state, running BW *
> # istr = 5 -> DS with reshuffling on all FS particles, standard BW *
> # istr = 6 -> DS with reshuffling on all FS particles, running BW *
> #******
> 1 = istr ! strategy to be used to remove resonances
>
> --
> You received this question notification because you are subscribed to
> the question.
|
Revision history for this message
|
#52 |
Dear Marco and Olivier,
So after implementing this NLO production in MG for tW and ttbar I showed my results.
They're interested in producing an official sample. It seems they do not have the most recent version integrated but I remember we only changed the
madgraph/
file to allow gamma-gluon for NLO.
we used the cards below, but as tW runs with MadSTRsPlugin we set the lpp2 to 2 by hand afterwards.
So I guess we can suggest the same procedure to the MC producers with the MG version they have available.
The other think is that I could help to see if we can make it part of the following version, without needing to modify the banner. We discussed we can show the XS is stable. We discussed above this can be done by using:
generate proton p > proton t t~
and applying a pt cut over the proton. So I can run with this configuration and maybe show the XS that are obtained?
TTBAR:
#import model sm-no_b_mass
generate p a > t t~ [QCD]
set automatic_
output jam_lpp2_
launch
launch
set lpp2 2
tW
import model sm-no_b_mass
define myw = w+ w-
define myt = t t~
generate p a > myt myw [QCD]
set automatic_
output jam_lpp2_
|
Revision history for this message
|
#53 |
So what we would need as validation is something like the plot of slide 10 of this presentation:
https:/
Is that answer your question?
Cheers,
Olivier
|
Revision history for this message
|
#54 |
Dear Olivier,
So I gave a look to slide 10.
Are we referring to the plot in the left or right or both?
In the plot in the left I don't understand why the XS of the total does not change with the pT min.
The other thing that is not clear is that if we are cutting on pT on the incoming or outgoing "proton" in (1) below. I guess the outgoing.
As I understand there are two processes to consider for this validation
(1) proton p > proton t t~
and
(2) a p > t t~
(1) would represent only one elastic proton, as in (2). We would be putting pT cut over the outgoing "proton" in (1), which will decrease the XS. But did not get what we do with (2). what I guess is that if the PT cut is large then that would correspond to (2) as ideally it has an intact outgoing proton with PT = 0.
The other question is that I'm using the "sm-no_b_mass" UFO model. but not sure how to use the p as "fundamental", I used the word "proton" but is not recognized. with p it uses g u c d s u~ c~ d~ s~. Should I use other UFO model?
And finally I imagine the cuts are set in the run card with:
{2212: 10.0} = pt_min_pdg ! pt cut for other particles (use pdg code). Applied on particle and anti-particle
Thanks
Javier
|
Revision history for this message
|
#55 |
> In the plot in the left I don't understand why the XS of the total does
> not change with the pT min.
That's the key point to check actually. This is a check that you can actually split the full cross-section (total)
into two complementary pieces and that such separation does not really depend of the scale that you choose for the splitting (which in this case is pt_min). In other word this check that you are correctly resumming the effect up to the separation scale.
> The other thing that is not clear is that if we are cutting on pT on the
> incoming or outgoing "proton" in (1) below. I guess the outgoing.
The initital state is always colinear (so 0 pt)
> (1) would represent only one elastic proton, as in (2). We would be
> putting pT cut over the outgoing "proton" in (1), which will decrease
> the XS. But did not get what we do with (2). what I guess is that if the
> PT cut is large then that would correspond to (2) as ideally it has an
> intact outgoing proton with PT = 0.
For (2) this is not per se a pt cut just the scale that you use to stop the resummation.
> The other question is that I'm using the "sm-no_b_mass" UFO model. but
> not sure how to use the p as "fundamental", I used the word "proton" but
> is not recognized. with p it uses g u c d s u~ c~ d~ s~. Should I use
> other UFO model?
If you need to have a "p" as fundamental then yes you need another UFO model.
The issue is to have a model which is still NLO otherwise this is pointless.
But I guess that adding a proton particle within the SM (NLO model) of FeynRules should be easy.
> And finally I imagine the cuts are set in the run card with:
>
> {2212: 10.0} = pt_min_pdg ! pt cut for other particles (use pdg code).
> Applied on particle and anti-particle
This might be working indeed (when you have "p" as a fondamental particle with at pdg code 2212)
Cheers,
Olivier
> On 21 Jan 2021, at 02:25, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Dear Olivier,
>
> So I gave a look to slide 10.
>
> Are we referring to the plot in the left or right or both?
>
> In the plot in the left I don't understand why the XS of the total does
> not change with the pT min.
>
> The other thing that is not clear is that if we are cutting on pT on the
> incoming or outgoing "proton" in (1) below. I guess the outgoing.
>
> As I understand there are two processes to consider for this validation
>
> (1) proton p > proton t t~
>
> and
>
> (2) a p > t t~
>
> (1) would represent only one elastic proton, as in (2). We would be
> putting pT cut over the outgoing "proton" in (1), which will decrease
> the XS. But did not get what we do with (2). what I guess is that if the
> PT cut is large then that would correspond to (2) as ideally it has an
> intact outgoing proton with PT = 0.
>
> The other question is that I'm using the "sm-no_b_mass" UFO model. but
> not sure how to use the p as "fundamental", I used the word "proton" but
> is not recognized. with p it uses g u c d s u~ c~ d~ s~. Should I use
> other UFO model?
>
> And finally I imagine the cuts are set in the run card with:
>
> {2212: 10.0} = pt_min_pdg ! pt cut for other particles (use pdg code).
> Applied on particle and anti-particle
>
> Thanks
>
> Javier
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
|
Revision history for this message
|
#56 |
Hello Olivier,
But then wouldn't it be better to check pt_max ? in
(1) proton p > proton t t~
cause if allowed pT max is small then that would correspond to a p > t t~.
If we do pt_min, large value means non-collinear proton and then no photoproduction and small allowed value should show as a small difference adding the photoproduction.
Secondly, do you know of a sm UFO model that has the proton as fundamental?
finally I wanted to ask about something a bit different.
So we produce our events with the following config:
import model sm-no_b_mass
generate p a > t t~ [QCD]
set automatic_
output jam_lpp2_
launch
launch
set lpp2 2
but when I add 'madspin' to handle the top decays, If I run over > 10k events then it starts showing some 'over_weight' issues and does not close the LHE file properly.
I put a summary below, this message.
If we run below 10k events it runs fine.
I add this cause it is preferred to use madspin to handle these top decays, but we are interested in the origin of these madspin weight errors.
Cheers
Javier
INFO: *******
* *
* W E L C O M E to M A D G R A P H 5 *
* a M C @ N L O *
* *
* * * *
* * * * * *
* * * * * 5 * * * * *
* * * * * *
* * * *
* *
* VERSION 5.2.8.0 20xx-xx-xx *
* *
* The MadGraph5_aMC@NLO Development Team - Find us at *
* http://
* *
* Type 'help' for in-line help. *
* *
*******
INFO: load configuration from /home/javier/
INFO: load configuration from /home/javier/
INFO: load configuration from /home/javier/
Using default text editor "vi". Set another one in ./input/
Using default eps viewer "evince". Set another one in ./input/
Using default web browser "firefox". Set another one in ./input/
launch
Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
| 3. Shower the generated events | shower = HERWIG6 | OFF|PYTHIA6Q|
| 4. Decay onshell particles | madspin = OFF | ON|onshell |
| 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
| 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'fixed_order=ON' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]
>shower=OFF
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
| 3. Shower the generated events | shower = OFF | PYTHIA6Q|
| 4. Decay onshell particles | madspin = OFF | ON|onshell |
| 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
| 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'fixed_order=ON' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.
>madspin=ON
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
| 3. Shower the generated events | shower = OFF | PYTHIA6Q|
| 4. Decay onshell particles | madspin = ON | onshell|OFF |
| 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
| 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'fixed_order=ON' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.
>
INFO: will run in mode: noshower
WARNING: You have chosen not to run a parton shower.
NLO events without showering are NOT physical.
Please, shower the LesHouches events before using them for physics analyses.
You have to choose NOW which parton-shower you WILL use and specify it in the run_card.
Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
Do you want to edit a card (press enter to bypass editing)?
/------
| 1. param : param_card.dat |
| 2. run : run_card.dat |
| 3. madspin : madspin_card.dat |
\------
you can also
- enter the path to a valid card or banner.
- use the 'set' command to modify a parameter directly.
The set option works only for param_card and run_card.
Type 'help set' for more information on this command.
- call an external program (ASperGE/
Type 'help' for the list of available command
[0, done, 1, param, 2, run, 3, madspin, enter path][90s to answer]
>
INFO: Update the dependent parameter of the param_card.dat
Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
INFO: Starting run
INFO: Compiling the code
Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
INFO: For gauge cancellation, the width of 't' has been set to zero.
INFO: Compiling source...
INFO: ...done, continuing with P* directories
INFO: Compiling directories...
INFO: Compiling on 4 cores
INFO: Compiling P0_ga_ttx...
INFO: P0_ga_ttx done.
INFO: Checking test output:
INFO: P0_ga_ttx
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for test_MC:
INFO: Passed.
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: Starting run
INFO: Using 4 cores
INFO: Cleaning previous results
INFO: Generating events without running the shower.
INFO: Setting up grids
INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h55 ]
INFO: Idle: 0, Running: 0, Completed: 2 [ 0.72s ]
INFO: Determining the number of unweighted events per channel
Intermediate results:
Random seed: 35
Total cross section: 6.912e-01 +- 7.6e-03 pb
Total abs(cross section): 1.018e+00 +- 9.8e-03 pb
INFO: Computing upper envelope
INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h55 ]
INFO: Idle: 0, Running: 1, Completed: 1 [ 10.9s ]
INFO: Idle: 0, Running: 0, Completed: 2 [ 10.9s ]
INFO: Updating the number of unweighted events per channel
Intermediate results:
Random seed: 35
Total cross section: 6.914e-01 +- 2.5e-03 pb
Total abs(cross section): 1.044e+00 +- 3.0e-03 pb
INFO: Generating events
INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h56 ]
INFO: Idle: 0, Running: 1, Completed: 1 [ 1m 5s ]
INFO: Idle: 0, Running: 0, Completed: 2 [ 1m 6s ]
INFO: Doing reweight
INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h57 ]
INFO: Idle: 0, Running: 1, Completed: 1 [ 11.1s ]
INFO: Idle: 0, Running: 0, Completed: 2 [ 11.7s ]
INFO: Collecting events
INFO:
----
Summary:
Process p a > t t~ [QCD]
Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
Number of events generated: 100000
Total cross section: 6.914e-01 +- 2.5e-03 pb
----
Scale variation (computed from LHE events):
----
INFO: The /home/javier/
INFO: Events generated
reweight -from_cards
decay_events -from_cards
INFO: Running MadSpin
INFO: This functionality allows for the decay of resonances
INFO: in a .lhe file, keeping track of the spin correlation effets.
INFO: BE AWARE OF THE CURRENT LIMITATIONS:
INFO: (1) Only a succession of 2 body decay are currently allowed
*******
* *
* W E L C O M E to M A D S P I N *
* *
*******
INFO: Extracting the banner ...
INFO: process: p a > t t~
INFO: options:
INFO: detected model: loop_sm-no_b_mass. Loading...
set ninja to /home/javier/
set lhapdf to /home/javier/
set collier to /home/javier/
set max_weight_ps_point 400 # number of PS to estimate the maximum for each event
decay t > w+ b, w+ > all all
decay t~ > w- b~, w- > all all
decay w+ > all all
decay w- > all all
decay z > all all
launch
INFO: Will use seed 810275352
INFO: We need to recalculate the branching fractions for t~,w-,z,w+,t
INFO: Using MadWidth (arXiv:1402.1178)
INFO: Restrict model /home/javier/
INFO: Run "set stdout_level DEBUG" before import for more information.
INFO:
INFO: decay channels for t~ : ( width = 1.4954 GeV )
INFO: BR d1 d2
INFO: 1.000000e+00 b~ w-
INFO:
INFO:
INFO: decay channels for w- : ( width = 2.04793 GeV )
INFO: BR d1 d2
INFO: 3.333610e-01 d u~
INFO: 3.333610e-01 s c~
INFO: 1.111195e-01 e- ve~
INFO: 1.111195e-01 mu- vm~
INFO: 1.110390e-01 ta- vt~
INFO:
INFO:
INFO: decay channels for z : ( width = 2.445696 GeV )
INFO: BR d1 d2
INFO: 1.521176e-01 d~ d
INFO: 1.521176e-01 s~ s
INFO: 1.521176e-01 b~ b
INFO: 1.186227e-01 u~ u
INFO: 1.186227e-01 c~ c
INFO: 6.782799e-02 ve~ ve
INFO: 6.782799e-02 vm~ vm
INFO: 6.782799e-02 vt~ vt
INFO: 3.433174e-02 e+ e-
INFO: 3.433174e-02 mu+ mu-
INFO: 3.425446e-02 ta+ ta-
INFO:
INFO:
INFO: decay channels for w+ : ( width = 2.04793 GeV )
INFO: BR d1 d2
INFO: 3.333610e-01 d~ u
INFO: 3.333610e-01 s~ c
INFO: 1.111195e-01 e+ ve
INFO: 1.111195e-01 mu+ vm
INFO: 1.110390e-01 ta+ vt
INFO:
INFO:
INFO: decay channels for t : ( width = 1.4954 GeV )
INFO: BR d1 d2
INFO: 1.000000e+00 b w+
INFO:
INFO: generating the production square matrix element
INFO: generate p a > t t~ --no_warning=
INFO: Done 1.264
INFO: generating the full matrix element squared (with decay)
INFO: generate p a > t t~, (t~ > b~ w- , w- > all all QCD=99), (t > b w+ , w+ > all all QCD=99) --no_warning=
INFO: Done 6.946
INFO: generate matrix element for decay only (1 - > N).
INFO: output standalone_msF /home/javier/
INFO: Done 1.133
INFO: Compiling code
INFO: detect independant decays
INFO: Done in 0.136081933975s
INFO:
INFO: Estimating the maximum weight
INFO: *******
INFO: Probing the first 139 events
INFO: with 400 phase space points
INFO:
INFO: Event 1/139 : 0.11s
INFO: Event 6/139 : 0.68s
INFO: Event 11/139 : 1.2s
INFO: Event 16/139 : 1.8s
INFO: Event 21/139 : 2.3s
INFO: Event 26/139 : 3s
INFO: Event 31/139 : 3.7s
INFO: Event 36/139 : 4.6s
INFO: Event 41/139 : 5.5s
INFO: Event 46/139 : 6.2s
INFO: Event 51/139 : 7.1s
INFO: Event 56/139 : 8.2s
INFO: Event 61/139 : 8.7s
INFO: Event 66/139 : 9.5s
INFO: Event 71/139 : 10.5s
INFO: Event 76/139 : 11.4s
INFO: Event 81/139 : 12.2s
INFO: Event 86/139 : 12.9s
INFO: Event 91/139 : 13.4s
INFO: Event 96/139 : 14s
INFO: Event 101/139 : 14.7s
INFO: Event 106/139 : 15.4s
INFO: Event 111/139 : 16.1s
INFO: Event 116/139 : 16.8s
INFO: Event 121/139 : 17.5s
INFO: Event 126/139 : 18.4s
INFO: Event 131/139 : 19.2s
INFO: Event 136/139 : 20.3s
INFO:
INFO: Decaying the events...
INFO: Event nb 1000 1.6s
INFO: Event nb 2000 2.8s
INFO: Event nb 3000 4s
INFO: Event nb 4000 5.3s
INFO: Event nb 5000 6.4s
INFO: Event nb 6000 7.6s
INFO: Event nb 7000 8.8s
INFO: Event nb 8000 10s
INFO: Event nb 9000 11.2s
INFO: Event nb 10000 12.3s
INFO: reducing number of print status. Next status update in 10000 events
INFO: Event nb 20000 23.8s
CRITICAL: over_weight: 3.38988093838 ('t_bwp_wp_sxc', 'tx_wmbx_
INFO: Event nb 30000 35.3s
INFO: Event nb 40000 46.5s
CRITICAL: over_weight: 2.39192373494 ('t_bwp_wp_dxu', 'tx_wmbx_
INFO: Event nb 50000 57.9s
INFO: Event nb 60000 1m 9s
INFO: Event nb 70000 1m 21s
INFO: Event nb 80000 1m 33s
INFO: Event nb 90000 1m 44s
INFO: Total number of events written: 100000/100000
INFO: Average number of trial points per production event: 5.55568
INFO: Branching ratio to allowed decays: 1
INFO: Number of events with weights larger than max_weight: 2
INFO: Number of subprocesses 24
INFO: Number of failures when restoring the Monte Carlo masses: 7
[3]- Done kate Cards/run_card.dat
Killed
|
Revision history for this message
|
#57 |
It is typically better to create one thread per question.
So I will only answer here question linked to this discussion, please open a new thread for the madspin one.
> If we do pt_min, large value means non-collinear proton and then no
> photoproduction and small allowed value should show as a small
> difference adding the photoproduction.
The point is that at pt=0 we have divergencies and the computation is meaningless. (So we need a pt_min)
This is one of the motivation of this contribution is to avoid such issue via a resumation.
The point here is to show the range in which you can set pt_min and have a consistent prediction.
> Secondly, do you know of a sm UFO model that has the proton as
> fundamental?
I do not, but Feynrules should be able to generate such model very easily in principle.
Cheers,
Olivier
> On 5 Feb 2021, at 04:01, Javier <email address hidden> wrote:
>
> Question #689742 on MadGraph5_aMC@NLO changed:
> https:/
>
> Javier posted a new comment:
> Hello Olivier,
>
> But then wouldn't it be better to check pt_max ? in
>
> (1) proton p > proton t t~
>
> cause if allowed pT max is small then that would correspond to a p > t
> t~.
>
> If we do pt_min, large value means non-collinear proton and then no
> photoproduction and small allowed value should show as a small
> difference adding the photoproduction.
>
> Secondly, do you know of a sm UFO model that has the proton as
> fundamental?
>
> finally I wanted to ask about something a bit different.
>
> So we produce our events with the following config:
>
> import model sm-no_b_mass
> generate p a > t t~ [QCD]
> set automatic_
> output jam_lpp2_
> launch
> launch
> set lpp2 2
>
> but when I add 'madspin' to handle the top decays, If I run over > 10k
> events then it starts showing some 'over_weight' issues and does not
> close the LHE file properly.
>
> I put a summary below, this message.
>
> If we run below 10k events it runs fine.
>
> I add this cause it is preferred to use madspin to handle these top
> decays, but we are interested in the origin of these madspin weight
> errors.
>
> Cheers
>
> Javier
>
> INFO: *******
> * *
> * W E L C O M E to M A D G R A P H 5 *
> * a M C @ N L O *
> * *
> * * * *
> * * * * * *
> * * * * * 5 * * * * *
> * * * * * *
> * * * *
> * *
> * VERSION 5.2.8.0 20xx-xx-xx *
> * *
> * The MadGraph5_aMC@NLO Development Team - Find us at *
> * http://
> * *
> * Type 'help' for in-line help. *
> * *
> *******
> INFO: load configuration from /home/javier/
> INFO: load configuration from /home/javier/
> INFO: load configuration from /home/javier/
> Using default text editor "vi". Set another one in ./input/
> Using default eps viewer "evince". Set another one in ./input/
> Using default web browser "firefox". Set another one in ./input/
> launch
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = HERWIG6 | OFF|PYTHIA6Q|
> | 4. Decay onshell particles | madspin = OFF | ON|onshell |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'fixed_order=ON' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]
>> shower=OFF
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = OFF | PYTHIA6Q|
> | 4. Decay onshell particles | madspin = OFF | ON|onshell |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'fixed_order=ON' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.
>> madspin=ON
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / event generation | fixed_order = OFF | ON |
> | 3. Shower the generated events | shower = OFF | PYTHIA6Q|
> | 4. Decay onshell particles | madspin = ON | onshell|OFF |
> | 5. Add weights to events for new hypp. | reweight = Not Avail. | Please install module |
> | 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
> \======
> Either type the switch number (1 to 6) to change its setting,
> Set any switch explicitly (e.g. type 'fixed_order=ON' at the prompt)
> Type 'help' for the list of all valid option
> Type '0', 'auto', 'done' or just press enter when you are done.
>>
> INFO: will run in mode: noshower
> WARNING: You have chosen not to run a parton shower.
> NLO events without showering are NOT physical.
> Please, shower the LesHouches events before using them for physics analyses.
> You have to choose NOW which parton-shower you WILL use and specify it in the run_card.
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> Do you want to edit a card (press enter to bypass editing)?
> /------
> | 1. param : param_card.dat |
> | 2. run : run_card.dat |
> | 3. madspin : madspin_card.dat |
> \------
> you can also
> - enter the path to a valid card or banner.
> - use the 'set' command to modify a parameter directly.
> The set option works only for param_card and run_card.
> Type 'help set' for more information on this command.
> - call an external program (ASperGE/
> Type 'help' for the list of available command
> [0, done, 1, param, 2, run, 3, madspin, enter path][90s to answer]
>>
> INFO: Update the dependent parameter of the param_card.dat
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> INFO: Starting run
> INFO: Compiling the code
> Lepton-lepton collisions: ignoring PDF related parameters in the run_card.dat (pdlabel, lhaid, reweight_pdf, ...)
> INFO: For gauge cancellation, the width of 't' has been set to zero.
> INFO: Compiling source...
> INFO: ...done, continuing with P* directories
> INFO: Compiling directories...
> INFO: Compiling on 4 cores
> INFO: Compiling P0_ga_ttx...
> INFO: P0_ga_ttx done.
> INFO: Checking test output:
> INFO: P0_ga_ttx
> INFO: Result for test_ME:
> INFO: Passed.
> INFO: Result for test_MC:
> INFO: Passed.
> INFO: Result for check_poles:
> INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
> INFO: Starting run
> INFO: Using 4 cores
> INFO: Cleaning previous results
> INFO: Generating events without running the shower.
> INFO: Setting up grids
> INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h55 ]
> INFO: Idle: 0, Running: 0, Completed: 2 [ 0.72s ]
> INFO: Determining the number of unweighted events per channel
>
> Intermediate results:
> Random seed: 35
> Total cross section: 6.912e-01 +- 7.6e-03 pb
> Total abs(cross section): 1.018e+00 +- 9.8e-03 pb
>
>
> INFO: Computing upper envelope
> INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h55 ]
> INFO: Idle: 0, Running: 1, Completed: 1 [ 10.9s ]
> INFO: Idle: 0, Running: 0, Completed: 2 [ 10.9s ]
> INFO: Updating the number of unweighted events per channel
>
> Intermediate results:
> Random seed: 35
> Total cross section: 6.914e-01 +- 2.5e-03 pb
> Total abs(cross section): 1.044e+00 +- 3.0e-03 pb
>
>
> INFO: Generating events
> INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h56 ]
> INFO: Idle: 0, Running: 1, Completed: 1 [ 1m 5s ]
> INFO: Idle: 0, Running: 0, Completed: 2 [ 1m 6s ]
> INFO: Doing reweight
> INFO: Idle: 0, Running: 2, Completed: 0 [ current time: 23h57 ]
> INFO: Idle: 0, Running: 1, Completed: 1 [ 11.1s ]
> INFO: Idle: 0, Running: 0, Completed: 2 [ 11.7s ]
> INFO: Collecting events
> INFO:
> -------
> Summary:
> Process p a > t t~ [QCD]
> Run at p-elastic photon from p collider (6500.0 + 6500.0 GeV)
> Number of events generated: 100000
> Total cross section: 6.914e-01 +- 2.5e-03 pb
> -------
> Scale variation (computed from LHE events):
> Dynamical_
> 6.916e-01 pb +4.0% -4.8%
> -------
>
> INFO: The /home/javier/
>
> INFO: Events generated
> reweight -from_cards
> decay_events -from_cards
> INFO: Running MadSpin
> INFO: This functionality allows for the decay of resonances
> INFO: in a .lhe file, keeping track of the spin correlation effets.
> INFO: BE AWARE OF THE CURRENT LIMITATIONS:
> INFO: (1) Only a succession of 2 body decay are currently allowed
> *******
> * *
> * W E L C O M E to M A D S P I N *
> * *
> *******
> INFO: Extracting the banner ...
> INFO: process: p a > t t~
> INFO: options:
> INFO: detected model: loop_sm-no_b_mass. Loading...
> set ninja to /home/javier/
> set lhapdf to /home/javier/
> set collier to /home/javier/
> set max_weight_ps_point 400 # number of PS to estimate the maximum for each event
> decay t > w+ b, w+ > all all
> decay t~ > w- b~, w- > all all
> decay w+ > all all
> decay w- > all all
> decay z > all all
> launch
> INFO: Will use seed 810275352
> INFO: We need to recalculate the branching fractions for t~,w-,z,w+,t
> INFO: Using MadWidth (arXiv:1402.1178)
> INFO: Restrict model /home/javier/
> INFO: Run "set stdout_level DEBUG" before import for more information.
> INFO:
> INFO: decay channels for t~ : ( width = 1.4954 GeV )
> INFO: BR d1 d2
> INFO: 1.000000e+00 b~ w-
> INFO:
> INFO:
> INFO: decay channels for w- : ( width = 2.04793 GeV )
> INFO: BR d1 d2
> INFO: 3.333610e-01 d u~
> INFO: 3.333610e-01 s c~
> INFO: 1.111195e-01 e- ve~
> INFO: 1.111195e-01 mu- vm~
> INFO: 1.110390e-01 ta- vt~
> INFO:
> INFO:
> INFO: decay channels for z : ( width = 2.445696 GeV )
> INFO: BR d1 d2
> INFO: 1.521176e-01 d~ d
> INFO: 1.521176e-01 s~ s
> INFO: 1.521176e-01 b~ b
> INFO: 1.186227e-01 u~ u
> INFO: 1.186227e-01 c~ c
> INFO: 6.782799e-02 ve~ ve
> INFO: 6.782799e-02 vm~ vm
> INFO: 6.782799e-02 vt~ vt
> INFO: 3.433174e-02 e+ e-
> INFO: 3.433174e-02 mu+ mu-
> INFO: 3.425446e-02 ta+ ta-
> INFO:
> INFO:
> INFO: decay channels for w+ : ( width = 2.04793 GeV )
> INFO: BR d1 d2
> INFO: 3.333610e-01 d~ u
> INFO: 3.333610e-01 s~ c
> INFO: 1.111195e-01 e+ ve
> INFO: 1.111195e-01 mu+ vm
> INFO: 1.110390e-01 ta+ vt
> INFO:
> INFO:
> INFO: decay channels for t : ( width = 1.4954 GeV )
> INFO: BR d1 d2
> INFO: 1.000000e+00 b w+
> INFO:
> INFO: generating the production square matrix element
> INFO: generate p a > t t~ --no_warning=
> INFO: Done 1.264
> INFO: generating the full matrix element squared (with decay)
> INFO: generate p a > t t~, (t~ > b~ w- , w- > all all QCD=99), (t > b w+ , w+ > all all QCD=99) --no_warning=
> INFO: Done 6.946
> INFO: generate matrix element for decay only (1 - > N).
> INFO: output standalone_msF /home/javier/
> INFO: Done 1.133
> INFO: Compiling code
> INFO: detect independant decays
> INFO: Done in 0.136081933975s
> INFO:
> INFO: Estimating the maximum weight
> INFO: *******
> INFO: Probing the first 139 events
> INFO: with 400 phase space points
> INFO:
> INFO: Event 1/139 : 0.11s
> INFO: Event 6/139 : 0.68s
> INFO: Event 11/139 : 1.2s
> INFO: Event 16/139 : 1.8s
> INFO: Event 21/139 : 2.3s
> INFO: Event 26/139 : 3s
> INFO: Event 31/139 : 3.7s
> INFO: Event 36/139 : 4.6s
> INFO: Event 41/139 : 5.5s
> INFO: Event 46/139 : 6.2s
> INFO: Event 51/139 : 7.1s
> INFO: Event 56/139 : 8.2s
> INFO: Event 61/139 : 8.7s
> INFO: Event 66/139 : 9.5s
> INFO: Event 71/139 : 10.5s
> INFO: Event 76/139 : 11.4s
> INFO: Event 81/139 : 12.2s
> INFO: Event 86/139 : 12.9s
> INFO: Event 91/139 : 13.4s
> INFO: Event 96/139 : 14s
> INFO: Event 101/139 : 14.7s
> INFO: Event 106/139 : 15.4s
> INFO: Event 111/139 : 16.1s
> INFO: Event 116/139 : 16.8s
> INFO: Event 121/139 : 17.5s
> INFO: Event 126/139 : 18.4s
> INFO: Event 131/139 : 19.2s
> INFO: Event 136/139 : 20.3s
> INFO:
> INFO: Decaying the events...
> INFO: Event nb 1000 1.6s
> INFO: Event nb 2000 2.8s
> INFO: Event nb 3000 4s
> INFO: Event nb 4000 5.3s
> INFO: Event nb 5000 6.4s
> INFO: Event nb 6000 7.6s
> INFO: Event nb 7000 8.8s
> INFO: Event nb 8000 10s
> INFO: Event nb 9000 11.2s
> INFO: Event nb 10000 12.3s
> INFO: reducing number of print status. Next status update in 10000 events
> INFO: Event nb 20000 23.8s
> CRITICAL: over_weight: 3.38988093838 ('t_bwp_wp_sxc', 'tx_wmbx_
> production_
>
> [decay.py at line 2301]
> INFO: Event nb 30000 35.3s
> INFO: Event nb 40000 46.5s
> CRITICAL: over_weight: 2.39192373494 ('t_bwp_wp_dxu', 'tx_wmbx_
> production_
>
> [decay.py at line 2301]
> INFO: Event nb 50000 57.9s
> INFO: Event nb 60000 1m 9s
> INFO: Event nb 70000 1m 21s
> INFO: Event nb 80000 1m 33s
> INFO: Event nb 90000 1m 44s
> INFO: Total number of events written: 100000/100000
> INFO: Average number of trial points per production event: 5.55568
> INFO: Branching ratio to allowed decays: 1
> INFO: Number of events with weights larger than max_weight: 2
> INFO: Number of subprocesses 24
> INFO: Number of failures when restoring the Monte Carlo masses: 7
> [3]- Done kate Cards/run_card.dat
> Killed
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
Can you help with this problem?
Provide an answer of your own, or ask Javier for more information if necessary.
