Rewighting issues: Pseudoscalar_2HDM

Asked by Shih-Chieh Hsu on 2019-06-26

Dear MadGraph experts,

I would like to use the reweighting features of the MadGraph for Pseudoscalar_2HDM model with UFO file below:
https://github.com/LHC-DMWG/model-repository/tree/master/models/Pseudoscalar_2HDM

In particular, I would like to study gluon induced process (loop-induced diagrams), i.e.
import model Pseudoscalar_2HDM -modelname
define p = g d u s c d~ u~ s~ c~
define j = g d u s c d~ u~ s~ c~
generate g g > h1 xd xd~ / z [QCD]

I setup my default parameter sinTheta=0.35, and would like to reweight it to sinTheta=0.55
launch --rwgt_name=SINP_0.55
set Higgs 5 0.55

If I just generate sinTheta=0.35, and sinTheta=0.55 directly, I found two models show similar total cross section, and similar kinematic distributions. However, the reweighted event weights can be one order of magnitude difference.

Do you expect that reweighting feature doesn't work for the loop-induced processes?

I attach link to a set of google slide with more details:
https://docs.google.com/presentation/d/1CKzu3VkK1W20QYDiXUbadwkEgUv8Oop9xIIocGhwkqM/edit?usp=sharing

Best,

Shih-Chieh

ps. I show both param_card.dat and run_card.dat in this email.

>
> param_card.dat
######################################################################
## PARAM_CARD AUTOMATICALY GENERATED BY THE UFO #####################
######################################################################

###################################
## INFORMATION FOR SMINPUTS
###################################
Block SMINPUTS
    1 1.279000e+02 # aEWM1
    2 1.166390e-05 # Gf
    3 1.180000e-01 # aS

###################################
## INFORMATION FOR MASS
###################################
Block MASS
     5 0.0 # MB
    6 1.720000e+02 # MT
   15 1.777000e+00 # MTA
   23 9.118760e+01 # MZ
   25 1.250000e+02 # mh1
     35 600 # mh2
     36 600 # mh3
     37 600 # mhc
     55 200 # mh4
     1000022 10.0 # MXd
## Not dependent paramater.
## Those values should be edited following analytical the
## analytical expression. Some generator could simply ignore
## those values and use the analytical expression
  22 0.000000 # a : 0.0
  24 79.824660 # W+ : cmath.sqrt(MZ**2/2. + cmath.sqrt(MZ**4/4. - (aEW*cmath.pi*MZ**2)/(Gf*cmath.sqrt(2))))
  21 0.000000 # g : 0.0
  9000001 0.000000 # ghA : 0.0
  9000003 79.824660 # ghWp : cmath.sqrt(MZ**2/2. + cmath.sqrt(MZ**4/4. - (aEW*cmath.pi*MZ**2)/(Gf*cmath.sqrt(2))))
  9000004 79.824660 # ghWm : cmath.sqrt(MZ**2/2. + cmath.sqrt(MZ**4/4. - (aEW*cmath.pi*MZ**2)/(Gf*cmath.sqrt(2))))
  82 0.000000 # ghG : 0.0
  12 0.000000 # ve : 0.0
  14 0.000000 # vm : 0.0
  16 0.000000 # vt : 0.0
  11 0.000000 # e- : 0.0
  13 0.000000 # mu- : 0.0
  2 0.000000 # u : 0.0
  4 0.000000 # c : 0.0
  1 0.000000 # d : 0.0
  3 0.000000 # s : 0.0
  251 79.824660 # G+ : cmath.sqrt(MZ**2/2. + cmath.sqrt(MZ**4/4. - (aEW*cmath.pi*MZ**2)/(Gf*cmath.sqrt(2))))
  9000002 91.187600 # ghZ : MZ
  250 91.187600 # G0 : MZ

###################################
## INFORMATION FOR DECAY
###################################
DECAY 6 1.508336e+00
DECAY 23 2.495200e+00
DECAY 24 2.085000e+00
DECAY 25 Auto
DECAY 35 Auto
DECAY 36 Auto
DECAY 37 Auto
DECAY 55 Auto
## Not dependent paramater.
## Those values should be edited following analytical the
## analytical expression. Some generator could simply ignore
## those values and use the analytical expression
DECAY 22 0.000000 # a : 0.0
DECAY 21 0.000000 # g : 0.0
DECAY 9000001 0.000000 # ghA : 0.0
DECAY 9000002 0.000000 # ghZ : 0.0
DECAY 9000003 0.000000 # ghWp : 0.0
DECAY 9000004 0.000000 # ghWm : 0.0
DECAY 82 0.000000 # ghG : 0.0
DECAY 12 0.000000 # ve : 0.0
DECAY 14 0.000000 # vm : 0.0
DECAY 16 0.000000 # vt : 0.0
DECAY 11 0.000000 # e- : 0.0
DECAY 13 0.000000 # mu- : 0.0
DECAY 15 0.000000 # ta- : 0.0
DECAY 2 0.000000 # u : 0.0
DECAY 4 0.000000 # c : 0.0
DECAY 1 0.000000 # d : 0.0
DECAY 3 0.000000 # s : 0.0
DECAY 5 0.000000 # b : 0.0
DECAY 1000022 0.000000 # Xd : 0.0
DECAY 250 2.495200 # G0 : WZ
DECAY 251 2.085000 # G+ : WW

###################################
## INFORMATION FOR DMINPUTS
###################################
Block DMINPUTS
     1 1.0 # gPXd

###################################
## INFORMATION FOR FRBLOCK
###################################
Block FRBlock
     2 10.0 # tanbeta
     3 1.0 # sinbma

###################################
## INFORMATION FOR HIGGS
###################################
Block Higgs
     1 3.0 # lam3
     2 3.0 # laP1
     3 3.0 # laP2
     5 0.1 # sinp

###################################
## INFORMATION FOR LOOP
###################################
Block LOOP
    1 9.118800e+01 # MU_R

###################################
## INFORMATION FOR YUKAWA
###################################
Block YUKAWA
    5 4.700000e+00 # ymb
    6 1.720000e+02 # ymt
   15 1.777000e+00 # ymtau
#===========================================================
# QUANTUM NUMBERS OF NEW STATE(S) (NON SM PDG CODE)
#===========================================================

Block QNUMBERS 9000001 # ghA
        1 0 # 3 times electric charge
        2 -1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 9000002 # ghZ
        1 0 # 3 times electric charge
        2 -1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 9000003 # ghWp
        1 3 # 3 times electric charge
        2 -1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 9000004 # ghWm
        1 -3 # 3 times electric charge
        2 -1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 82 # ghG
        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/Antiparticle distinction (0=own anti)
Block QNUMBERS 250 # G0
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 0 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 251 # G+
        1 3 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 37 # h+
        1 3 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 35 # h2
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 0 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 36 # h3
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 0 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 55 # h4
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 0 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 1000022 # Xd
        1 0 # 3 times electric charge
        2 2 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)

>run_card.dat
#*********************************************************************
# MadGraph5_aMC@NLO *
# *
# run_card.dat MadEvent *
# *
# This file is used to set the parameters of the run. *
# *
# Some notation/conventions: *
# *
# Lines starting with a '# ' are info or comments *
# *
# mind the format: value = variable ! comment *
# *
# To display more options, you can type the command: *
# update full_run_card *
#*********************************************************************
#
#*******************
# Running parameters
#*******************
#
#*********************************************************************
# Tag name for the run (one word) *
#*********************************************************************
  tag_1 = run_tag ! name of the run
#*********************************************************************
# Number of events and rnd seed *
# Warning: Do not generate more than 1M events in a single run *
# If you want to run Pythia, avoid more than 50k events in a run. *
#*********************************************************************
  10000 = nevents ! Number of unweighted events requested
   123456 = iseed ! rnd seed (0=assigned automatically=default))
#*********************************************************************
# Collider type and energy *
# lpp: 0=No PDF, 1=proton, -1=antiproton, 2=photon from proton, *
# 3=photon from electron *
#*********************************************************************
     1 = lpp1 ! beam 1 type
     1 = lpp2 ! beam 2 type
   6500 = ebeam1 ! beam 1 energy in GeV
   6500 = ebeam2 ! beam 2 energy in GeV
# To see polarised beam options: type "update beam_pol"
#*********************************************************************
# PDF CHOICE: this automatically fixes also alpha_s and its evol. *
#*********************************************************************
 'lhapdf' = pdlabel ! PDF set
 260000 = lhaid ! if pdlabel=lhapdf, this is the lhapdf number
# To see heavy ion options: type "update ion_pdf"
#*********************************************************************
# Renormalization and factorization scales *
#*********************************************************************
 False = fixed_ren_scale ! if .true. use fixed ren scale
 False = fixed_fac_scale ! if .true. use fixed fac scale
 91.188 = scale ! fixed ren scale
 91.188 = dsqrt_q2fact1 ! fixed fact scale for pdf1
 91.188 = dsqrt_q2fact2 ! fixed fact scale for pdf2
 -1 = dynamical_scale_choice ! Choose one of the preselected dynamical choices
 1.00 = scalefact ! scale factor for event-by-event scales
#*********************************************************************
# Type and output format
#*********************************************************************
  False = gridpack !True = setting up the grid pack
  -1.0 = time_of_flight ! threshold (in mm) below which the invariant livetime is not written (-1 means not written)
 3.0 = lhe_version ! Change the way clustering information pass to shower.
  True = clusinfo ! include clustering tag in output
  average = event_norm ! average/sum. Normalization of the weight in the LHEF

#*********************************************************************
# Matching parameter (MLM only)
#*********************************************************************
 0 = ickkw ! 0 no matching, 1 MLM
 1.00 = alpsfact ! scale factor for QCD emission vx
 False = chcluster ! cluster only according to channel diag
 5 = asrwgtflavor ! highest quark flavor for a_s reweight
 False = auto_ptj_mjj ! Automatic setting of ptj and mjj if xqcut >0
                                   ! (turn off for VBF and single top processes)
0.000000 = xqcut ! minimum kt jet measure between partons
#*********************************************************************
#
#*********************************************************************
# handling of the helicities:
# 0: sum over all helicities
# 1: importance sampling over helicities
#*********************************************************************
   0 = nhel ! using helicities importance sampling or not.
#*********************************************************************
# Generation bias, check the wiki page below for more information: *
# 'cp3.irmp.ucl.ac.be/projects/madgraph/wiki/LOEventGenerationBias' *
#*********************************************************************
 None = bias_module ! Bias type of bias, [None, ptj_bias, -custom_folder-]
 {} = bias_parameters ! Specifies the parameters of the module.
#
#*******************************
# Parton level cuts definition *
#*******************************
#
#
#*********************************************************************
# BW cutoff (M+/-bwcutoff*Gamma) ! Define on/off-shell for "$" and decay
#*********************************************************************
  15.0 = bwcutoff ! (M+/-bwcutoff*Gamma)
#*********************************************************************
# Apply pt/E/eta/dr/mij/kt_durham cuts on decay products or not
# (note that etmiss/ptll/ptheavy/ht/sorted cuts always apply)
#*********************************************************************
 F = cut_decays ! Cut decay products
#*********************************************************************
# Standard Cuts *
#*********************************************************************
# Minimum and maximum pt's (for max, -1 means no cut) *
#*********************************************************************
 20.0 = ptj ! minimum pt for the jets
 0.0 = ptb ! minimum pt for the b
 10.0 = pta ! minimum pt for the photons
 10.0 = ptl ! minimum pt for the charged leptons
 0.0 = misset ! minimum missing Et (sum of neutrino's momenta)
 -1.0 = ptjmax ! maximum pt for the jets
 -1.0 = ptbmax ! maximum pt for the b
 -1.0 = ptamax ! maximum pt for the photons
 -1.0 = ptlmax ! maximum pt for the charged leptons
 -1.0 = missetmax ! maximum missing Et (sum of neutrino's momenta)
 {} = pt_min_pdg ! pt cut for other particles (use pdg code). Applied on particle and anti-particle
 {} = pt_max_pdg ! pt cut for other particles (syntax e.g. {6: 100, 25: 50})
#*********************************************************************
# Minimum and maximum E's (in the center of mass frame) *
#*********************************************************************
  0.0 = ej ! minimum E for the jets
  0.0 = eb ! minimum E for the b
  0.0 = ea ! minimum E for the photons
  0.0 = el ! minimum E for the charged leptons
  -1.0 = ejmax ! maximum E for the jets
 -1.0 = ebmax ! maximum E for the b
 -1.0 = eamax ! maximum E for the photons
 -1.0 = elmax ! maximum E for the charged leptons
 {} = e_min_pdg ! E cut for other particles (use pdg code). Applied on particle and anti-particle
 {} = e_max_pdg ! E cut for other particles (syntax e.g. {6: 100, 25: 50})
#*********************************************************************
# Maximum and minimum absolute rapidity (for max, -1 means no cut) *
#*********************************************************************
  5.0 = etaj ! max rap for the jets
  -1.0 = etab ! max rap for the b
 2.5 = etaa ! max rap for the photons
 2.5 = etal ! max rap for the charged leptons
 0.0 = etajmin ! min rap for the jets
 0.0 = etabmin ! min rap for the b
 0.0 = etaamin ! min rap for the photons
 0.0 = etalmin ! main rap for the charged leptons
 {} = eta_min_pdg ! rap cut for other particles (use pdg code). Applied on particle and anti-particle
 {} = eta_max_pdg ! rap cut for other particles (syntax e.g. {6: 2.5, 23: 5})
#*********************************************************************
# Minimum and maximum DeltaR distance *
#*********************************************************************
 0.4 = drjj ! min distance between jets
 0.0 = drbb ! min distance between b's
 0.4 = drll ! min distance between leptons
 0.4 = draa ! min distance between gammas
 0.0 = drbj ! min distance between b and jet
 0.4 = draj ! min distance between gamma and jet
 0.4 = drjl ! min distance between jet and lepton
 0.0 = drab ! min distance between gamma and b
 0.0 = drbl ! min distance between b and lepton
 0.4 = dral ! min distance between gamma and lepton
 -1.0 = drjjmax ! max distance between jets
 -1.0 = drbbmax ! max distance between b's
 -1.0 = drllmax ! max distance between leptons
 -1.0 = draamax ! max distance between gammas
 -1.0 = drbjmax ! max distance between b and jet
 -1.0 = drajmax ! max distance between gamma and jet
 -1.0 = drjlmax ! max distance between jet and lepton
 -1.0 = drabmax ! max distance between gamma and b
 -1.0 = drblmax ! max distance between b and lepton
 -1.0 = dralmax ! maxdistance between gamma and lepton
#*********************************************************************
# Minimum and maximum invariant mass for pairs *
# WARNING: for four lepton final state mmll cut require to have *
# different lepton masses for each flavor! *
#*********************************************************************
 0.0 = mmjj ! min invariant mass of a jet pair
 0.0 = mmbb ! min invariant mass of a b pair
 0.0 = mmaa ! min invariant mass of gamma gamma pair
 0.0 = mmll ! min invariant mass of l+l- (same flavour) lepton pair
 -1.0 = mmjjmax ! max invariant mass of a jet pair
 -1.0 = mmbbmax ! max invariant mass of a b pair
 -1.0 = mmaamax ! max invariant mass of gamma gamma pair
 -1.0 = mmllmax ! max invariant mass of l+l- (same flavour) lepton pair
 {} = mxx_min_pdg ! min invariant mass of a pair of particles X/X~ (e.g. {6:250})
 {'default': False} = mxx_only_part_antipart ! if True the invariant mass is applied only
                       ! to pairs of particle/antiparticle and not to pairs of the same pdg codes.
#*********************************************************************
# Minimum and maximum invariant mass for all letpons *
#*********************************************************************
 0.0 = mmnl ! min invariant mass for all letpons (l+- and vl)
 -1.0 = mmnlmax ! max invariant mass for all letpons (l+- and vl)
#*********************************************************************
# Minimum and maximum pt for 4-momenta sum of leptons *
#*********************************************************************
 0.0 = ptllmin ! Minimum pt for 4-momenta sum of leptons(l and vl)
 -1.0 = ptllmax ! Maximum pt for 4-momenta sum of leptons(l and vl)
#*********************************************************************
# Inclusive cuts *
#*********************************************************************
 0.0 = ptheavy ! minimum pt for at least one heavy final state
 0.0 = xptj ! minimum pt for at least one jet
 0.0 = xptb ! minimum pt for at least one b
 0.0 = xpta ! minimum pt for at least one photon
 0.0 = xptl ! minimum pt for at least one charged lepton
#*********************************************************************
# Control the pt's of the jets sorted by pt *
#*********************************************************************
 0.0 = ptj1min ! minimum pt for the leading jet in pt
 0.0 = ptj2min ! minimum pt for the second jet in pt
 0.0 = ptj3min ! minimum pt for the third jet in pt
 0.0 = ptj4min ! minimum pt for the fourth jet in pt
 -1.0 = ptj1max ! maximum pt for the leading jet in pt
 -1.0 = ptj2max ! maximum pt for the second jet in pt
 -1.0 = ptj3max ! maximum pt for the third jet in pt
 -1.0 = ptj4max ! maximum pt for the fourth jet in pt
 0 = cutuse ! reject event if fails any (0) / all (1) jet pt cuts
#*********************************************************************
# Control the pt's of leptons sorted by pt *
#*********************************************************************
 0.0 = ptl1min ! minimum pt for the leading lepton in pt
 0.0 = ptl2min ! minimum pt for the second lepton in pt
 0.0 = ptl3min ! minimum pt for the third lepton in pt
 0.0 = ptl4min ! minimum pt for the fourth lepton in pt
 -1.0 = ptl1max ! maximum pt for the leading lepton in pt
 -1.0 = ptl2max ! maximum pt for the second lepton in pt
 -1.0 = ptl3max ! maximum pt for the third lepton in pt
 -1.0 = ptl4max ! maximum pt for the fourth lepton in pt
#*********************************************************************
# Control the Ht(k)=Sum of k leading jets *
#*********************************************************************
 0.0 = htjmin ! minimum jet HT=Sum(jet pt)
 -1.0 = htjmax ! maximum jet HT=Sum(jet pt)
 0.0 = ihtmin !inclusive Ht for all partons (including b)
 -1.0 = ihtmax !inclusive Ht for all partons (including b)
 0.0 = ht2min ! minimum Ht for the two leading jets
 0.0 = ht3min ! minimum Ht for the three leading jets
 0.0 = ht4min ! minimum Ht for the four leading jets
 -1.0 = ht2max ! maximum Ht for the two leading jets
 -1.0 = ht3max ! maximum Ht for the three leading jets
 -1.0 = ht4max ! maximum Ht for the four leading jets
#***********************************************************************
# Photon-isolation cuts, according to hep-ph/9801442 *
# When ptgmin=0, all the other parameters are ignored *
# When ptgmin>0, pta and draj are not going to be used *
#***********************************************************************
 0.0 = ptgmin ! Min photon transverse momentum
 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)
#*********************************************************************
# WBF cuts *
#*********************************************************************
 0.0 = xetamin ! minimum rapidity for two jets in the WBF case
 0.0 = deltaeta ! minimum rapidity for two jets in the WBF case
#***********************************************************************
# Turn on either the ktdurham or ptlund cut to activate *
# CKKW(L) merging with Pythia8 [arXiv:1410.3012, arXiv:1109.4829] *
#***********************************************************************
 -1.0 = ktdurham
 0.4 = dparameter
 -1.0 = ptlund
 1, 2, 3, 4, 5, 6, 21, 82 = pdgs_for_merging_cut ! PDGs for two cuts above
#*********************************************************************
# maximal pdg code for quark to be considered as a light jet *
# (otherwise b cuts are applied) *
#*********************************************************************
 5 = maxjetflavor ! Maximum jet pdg code
#*********************************************************************
#
#*********************************************************************
# Store info for systematics studies *
# WARNING: Do not use for interference type of computation *
#*********************************************************************
 True = use_syst ! Enable systematics studies
#
systematics = systematics_program ! none, systematics [python], SysCalc [depreceted, C++]
['--mur=0.5,1,2', '--muf=0.5,1,2', '--pdf=errorset'] = systematics_arguments ! see: https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/Systematics#Systematicspythonmodule
# Syscalc is deprecated but to see the associate options type'update syscalc'
 NNPDF30_nlo_as_0118 = sys_pdf

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2019-06-26
Last reply:
2019-09-03

>Do you expect that reweighting feature doesn't work for the loop-induced processes?

No it is at the same level as other type of re-weighting.

> If I just generate sinTheta=0.35, and sinTheta=0.55 directly, I found two models show similar total cross section, and similar kinematic distributions. However, the reweighted event weights can be one order of magnitude difference.

I do not consider that as a problem. what is the dependence of your matrix-element in that parameter?
if your matrix-element can be proportional to sinTheta^2 (in some part of the phase-space) then the matrix-element square will be proportional to sinTheta^4 which gives you a typical re-weighting factor of 0.55**4/0.35**4 = 6.0978758850479.
I do not know your model, but naively a factor up to 36 (if you have two of such coupling) seems quite expected.

Cheers,

Olivier

Hi,

The normalisation of the weight is not fully fixed and can depend of the parton-shower that you are using.
In general, you have to take the average of the weight in order to get the cross-section and not the sum.
The re-weighting approach (has to) follow the convention used from the main weight of the events.
This is the convention decided in the lhef version3 paper: See arXiv:1405.1067

Concerning the official paper related to the reweighting, here it is: arXiv:1607.00763

Cheers,

Olivier

Chris (christopher-anelli) said : #3

Hi Olivier,

Shih-Chieh can correct me if I am mistaken, but I believe his point is that the cross-sections calculated by the MG Reweighting module can be an order of magnitude different than the cross section for the same point calculated via the full generation. This is particularly surprising for the two points he mentions given they have similar final state kinematics and similar cross sections (so one would one naively expect the reweighting weights to be small.)

Working on a similar analysis, "generate g g > z xd xd~ / h1 [QCD]", I see the same issue. Beyond needing to covering the same phase-space, are there other conditions under which the the reweighting can be less accurate?

I do not believe this is a PS issue because the discrepancy in cross sections is present at the lhe level. I am also a little confused by the comment about needing to normalize to the average weight and not the sum? Wouldn't one calculate the average weight by taking the sum of weights. The paper, arXiv:1607.00763, also says cross-section is taken as the sum of weights, and I can confirm that cross sections calculated using the sum of weights matches the values printed out by the MG Reweighting module.

Thank you for your help clarifying the reweighting procedure.

Best

Chris

Hi,

> Shih-Chieh can correct me if I am mistaken, but I believe his point is
> that the cross-sections calculated by the MG Reweighting module can be
> an order of magnitude different than the cross section for the same
> point calculated via the full generation. This is particularly
> surprising for the two points he mentions given they have similar final
> state kinematics and similar cross sections (so one would one naively
> expect the reweighting weights to be small.)

This is a point to clarify is the problem at the total cross-section level or is he/you only worry
about the weight distribution.

> Working on a similar analysis, "generate g g > z xd xd~ / h1 [QCD]", I
> see the same issue. Beyond needing to covering the same phase-space,
> are there other conditions under which the the reweighting can be less
> accurate?

Everything is written in the paper: arXiv:1607.00763
But you have four factors:
1) phase-space domain (can lead to systematics bias)
2) phase-space covering (can lead to statistical error)
3) helicity domain/covering (can lead to both. can be avoid if you do not use the helicity information)
4) leading color information (no re-weighting on that information -> can lead to bias in the parton-shower if some weight should have been associated to this factor)

The helicity is a source of a lot of issue since people quite often do not realise those effects.
You can try to force the re-weighting by the helicity average to see if this solves your issue.
(But then you can not use the associate information in any way)

> I do not believe this is a PS issue because the discrepancy in cross
> sections is present at the lhe level. I am also a little confused by
> the comment about needing to normalize to the average weight and not the
> sum? Wouldn't one calculate the average weight by taking the sum of
> weights.

They are no convention on the normalisation of the weight.
I personally prefer to normalise my weight such that the sum of weight gives the cross-section.
But many MC authors (at least from the MG5aMC tools and from PY8 tools) prefer to have events where the average of the weight are normalise to the cross-section.
Additionally, some experimentalist prefer that the weight to be 1 for un-weighted sample (and therefore not related to the cross-section)

MG5aMC supports the three schemes of weights and the user can decide which one to use.
For a long time at LO, the default was to use the sum, and we switch at one point to the average to have the same convention as the NLO case.

So I keep my previous statement: "In general, you have to take the average of the weight in order to get the cross-section and not the sum. The re-weighting approach (has to) follow the convention used from the main weight of the events."

> The paper, arXiv:1607.00763, also says cross-section is taken
> as the sum of weights.

As I said I prefer that convention, so yes I used that one. But as explained above this is the user choice which one to use (up to some exception). At the theoretical level, it is much more easy to explain/proof the re-weighting with that convention compare to the other two.

> I can confirm that cross sections calculated
> using the sum of weights matches the values printed out by the MG
> Reweighting module.

Certainly possible.

Cheers,

Olivier

> On 28 Jun 2019, at 08:58, Chris <email address hidden> wrote:
>
> Question #681610 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/681610
>
> Chris requested more information:
> Hi Olivier,
>
> Shih-Chieh can correct me if I am mistaken, but I believe his point is
> that the cross-sections calculated by the MG Reweighting module can be
> an order of magnitude different than the cross section for the same
> point calculated via the full generation. This is particularly
> surprising for the two points he mentions given they have similar final
> state kinematics and similar cross sections (so one would one naively
> expect the reweighting weights to be small.)
>
> Working on a similar analysis, "generate g g > z xd xd~ / h1 [QCD]", I
> see the same issue. Beyond needing to covering the same phase-space,
> are there other conditions under which the the reweighting can be less
> accurate?
>
> I do not believe this is a PS issue because the discrepancy in cross
> sections is present at the lhe level. I am also a little confused by
> the comment about needing to normalize to the average weight and not the
> sum? Wouldn't one calculate the average weight by taking the sum of
> weights. The paper, arXiv:1607.00763, also says cross-section is taken
> as the sum of weights, and I can confirm that cross sections calculated
> using the sum of weights matches the values printed out by the MG
> Reweighting module.
>
> Thank you for your help clarifying the reweighting procedure.
>
> Best
>
> Chris
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Just to say that from Shih-Chieh's cards it seems that he is using the average:

average = event_norm ! average/sum. Normalization of the weight in the LHEF

(and independent of that this is something that should be discussed within ATLAS PMG too, since it's not the default that we use).

Best,
Spyros

Chris (christopher-anelli) said : #6

Hi Olivier,

Discussing with Shih-Chieh, is it possible that difference in the reweighted samples is related to the particle decay widths? The widths are currently auto calculated, but implicitly depend on the parameter we are varying. Does the Reweighting module recalculate the widths?

Best

Chris

Hi,

Depends what "auto" calculated means.

if you mean that you were using "Auto" within the param_card in the original run,
then when using
launch --rwgt_name=SINP_0.55
set Higgs 5 0.55
You would need to also add
set decay XX Auto
to have that benchmark to compute the width (otherwise it will use the same one as the original param_card)

If you mean that the width of that particle is an internal parameter of the model and that MG5aMC does not read such line then in that case, the width is recomputed.

Cheers,

Olivier

Chris (christopher-anelli) said : #8

Hi Olivier,

Following up on this thread. Even when including "set decay XX Auto", for scans of sinTheta for the g g > h1 xd xd~ / z [QCD] process, we still see an order of magnitude difference between the directly generated cross sections and those calculated with the Reweighting Tool. This is surprising given that the discrepancy appears even for samples that cover similar regions of phase space, ie
sinTheta=0.35 reweighted to sinTheta=0.55.

Best

Chris

Chris (christopher-anelli) said : #9

Hi Olivier,
Is there a preferred way to attach MG cards / log files, instead pasting them into the comments?
Best
Chris

Open a bug report instead of asking a question. You attach file for bug report but you can not for questions

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: <email address hidden> <email address hidden> on behalf of Chris <email address hidden>
Sent: Tuesday, September 3, 2019 6:07:43 PM
To: Olivier Mattelaer <email address hidden>
Subject: Re: [Question #681610]: Rewighting issues: Pseudoscalar_2HDM

Question #681610 on MadGraph5_aMC@NLO changed:
https://answers.launchpad.net/mg5amcnlo/+question/681610

Chris requested more information:
Hi Olivier,
Is there a preferred way to attach MG cards / log files, instead pasting them into the comments?
Best
Chris

--
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 Shih-Chieh Hsu for more information if necessary.

To post a message you must log in.