Running Loop Induced pp->zz+2jet gives error results.dat not found

Asked by Jay Sandesara on 2020-08-13

Hey,

I recently generated 2k events for gg->zzgg process using MadGraph. I now want to do the full pp->zzjj process. For this I use a filter that removes all diagrams that do not have a quark loop plus a Higgs/Z boson/photon attached to the loop. This worked well for the pp->zzj process and I got 10k events. However for the 2 jet process, after some jobs are complete I get the following log:

INFO: Idle: 899, Running: 80, Completed: 440 [ 62h 51m ]
STOP 4
rm: cannot remove `results.dat': No such file or directory
ERROR DETECTED
INFO: Idle: 898, Running: 80, Completed: 441 [ 62h 51m ]

And then it continues and again I get a similar error but it keeps continuing. After going through some other questions here that have gotten similar errors, I tried to correct the scale choice from the default to 3 (which I think is Ht/2). However, I still end up getting the same error. I am hoping that I do not have to wait for the full process to be done before I can figure out whats going wrong since it will take possibly 8-9 days based on previous ggzzgg production experience. Is there any way I can figure out whats going wrong here?

For the run_card I use the following matching settings:

 1 = ickkw ! 0 no matching, 1 MLM
 1.0 = alpsfact ! scale factor for QCD emission vx
 False = chcluster ! cluster only according to channel diag
 4 = 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)
 5.0 = xqcut ! minimum kt jet measure between partons

I had to set auto_ptj_mjj to False since the 2 jet process seems to contain diagrams that have non-QCD jets. (qqZ vertex).

Heres the full proc card and run card:

#*********************************************************************
# 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 *
#*********************************************************************
#
#*********************************************************************
# 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 *
#*********************************************************************
  2000 = nevents ! Number of unweighted events requested
  0 = 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.0 = ebeam1 ! beam 1 total energy in GeV
  6500.0 = ebeam2 ! beam 2 total energy in GeV
# To see polarised beam options: type "update beam_pol"

#*********************************************************************
# PDF CHOICE: this automatically fixes also alpha_s and its evol. *
#*********************************************************************
  nn23lo1 = pdlabel ! PDF set
  230000 = 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
  3 = dynamical_scale_choice ! Choose one of the preselected dynamical choices
  1.0 = 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)
  average = event_norm ! average/sum. Normalization of the weight in the LHEF
# To see MLM/CKKW merging options: type "update MLM" or "update CKKW"
#*********************************************************************
# Matching parameter (MLM only)
#*********************************************************************
 1 = ickkw ! 0 no matching, 1 MLM
 1.0 = alpsfact ! scale factor for QCD emission vx
 False = chcluster ! cluster only according to channel diag
 4 = 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)
 5.0 = xqcut ! minimum kt jet measure between partons
#*********************************************************************
#
#*********************************************************************
# handling of the helicities:
# 0: sum over all helicities
# 1: importance sampling over helicities
#*********************************************************************
  1 = 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)
#*********************************************************************
# Standard Cuts *
#*********************************************************************
# Minimum and maximum pt's (for max, -1 means no cut) *
#*********************************************************************
  0.0 = ptj ! minimum pt for the jets
  -1.0 = ptjmax ! maximum pt for the jets
  {} = 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})
#
# For display option for energy cut in the partonic center of mass frame type 'update ecut'
#
#*********************************************************************
# Maximum and minimum absolute rapidity (for max, -1 means no cut) *
#*********************************************************************
  -1.0 = etaj ! max rap for the jets
  {} = 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.0 = draa
 0.0 = draj
 0.0 = ptb
 0.0 = pta
 -1.0 = etab
 -1.0 = etaa
  0.0 = drjj ! min distance between jets
  -1.0 = drjjmax ! max distance between jets
#*********************************************************************
# Minimum and maximum invariant mass for pairs *
#*********************************************************************
  0.0 = mmjj ! min invariant mass of a jet pair
  -1.0 = mmjjmax ! max invariant mass of a jet 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.
#*********************************************************************
# Inclusive cuts *
#*********************************************************************
  0.0 = ptheavy ! minimum pt for at least one heavy final state
  0.0 = xptj ! minimum pt for at least one jet
 #*********************************************************************
 # 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
  -1.0 = ptj1max ! maximum pt for the leading jet in pt
  -1.0 = ptj2max ! maximum pt for the second jet in pt
  0 = cutuse ! reject event if fails any (0) / all (1) jet pt cuts
 #*********************************************************************
 # 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)
 #*********************************************************************
 # 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
#*********************************************************************
# maximal pdg code for quark to be considered as a light jet *
# (otherwise b cuts are applied) *
#*********************************************************************
  4 = maxjetflavor ! Maximum jet pdg code
#*********************************************************************
#
#*********************************************************************
# Store info for systematics studies *
# WARNING: Do not use for interference type of computation *
#*********************************************************************
  False = 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'

#************************************************************
#* MadGraph5_aMC@NLO *
#* *
#* * * *
#* * * * * *
#* * * * * 5 * * * * *
#* * * * * *
#* * * *
#* *
#* *
#* VERSION 2.7.2 2020-03-17 *
#* *
#* The MadGraph5_aMC@NLO Development Team - Find us at *
#* https://server06.fynu.ucl.ac.be/projects/madgraph *
#* *
#************************************************************
#* *
#* Command File for MadGraph5_aMC@NLO *
#* *
#* run as ./bin/mg5_aMC filename *
#* *
#************************************************************
set default_unset_couplings 99
set group_subprocesses Auto
set ignore_six_quark_processes False
set loop_optimized_output True
set loop_color_flows False
set gauge unitary
set complex_mass_scheme False
set max_npoint_for_channel 0
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~
set max_npoint_for_channel = 6
import model loop_sm
generate p p > z z j j [noborn=QCD]
output pp4lep2jet

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
Valentin Hirschi Edit question
Last query:
2020-08-24
Last reply:
2020-09-07

The stop 4 is a clear indication that the matching within MG5aMC fails to work.
Matching/merging for those type of process are quite touchy since the parton shower will not include any of the kernel that involves loop. We did validated it for Higgs production up to 2 jet, but nothing assure that MLM will work for such type of Z production.

Concerning the error message, you can kill your jobs, in principle the error message is in the log file, the issue with killing them is that you will need to find the correct job with that message. For that you should look at all the results.dat file and find those who have a message like "end code not correct"

Not sure that i can help for this one. Which version are you using?
If you are using the latest one, if not the best I can suggest is to hack madgraph to bypass the error and accept the scale even if it obviously wrong for some phase-space configuration).

For that you will have to edit
SubProcesses/reweight.f
at around line 988
and change
 if (fail) then
to
if (.false.)

This is obviously a change that question the validity of the output (even more than the issue of the PS missing some kernel)

Cheers,

Olivier

Jay Sandesara (jaysandesara) said : #2

Hey Olivier,

Thanks for the answer! I have just a few follow up questions:

I understand that this type of matching with loop induced isn't fully tested. However, recently a paper came out that did this type of merging using MadGraph+Pythia with a similar process: https://arxiv.org/pdf/2006.12860.pdf

The difference was they generated all 3 different multiplicity samples together, and they excluded the Higgs mediated diagrams.
Do you think that doing either of these things might help remove the error? Or could it simply be an issue with say a cut in the jets or something that causes the matching error?

We would prefer not to follow their lead since we are hoping to use the full power of MadGraph with its spin correlations and off-shell Z effects to generate the 0,1 jet sample and then use the 2 jet sample to assess systematic uncertainties related to the jet system.

I tried searching for error in the SubProcesses directory but its like needle in a haystack with the multitude of results.dat file for this process. If it helps the case, the matching also worked quite well with 0+1 jet loop induced samples (only difference being I used the full 4 lepton final state with MadGraph instead of zz and used auto_ptj_mjj = True during event generation.) We tested it and got very good plots.

Thanks,
Jay Sandesara

Jay Sandesara (jaysandesara) said : #3

Hey Olivier,

So I managed to find the results.dat containing the end code error using a string search. Thanks!

Apparently the error is stemming from the ggzzqq processes. Here are some of the errors found in the log.txt of failed jobs:

Error: Failed despite same graph: 55
STOP 4
 Have jets (>0) 0 0 0 0 0 1
 Should be

 Error: Failed despite same graph: 55
STOP 4
 Have jets (>0) 0 0 0 0 0 0
 Should be 6

And so on. They seem to be coming from directories named ./P0_gg_zzqq/G53_* where * goes from 1 to 8.

What do you think?

Thanks,
Jay Sandesara

Jay Sandesara (jaysandesara) said : #4

In case it helps determine the source of error, I have moved the diagrams associated with ggzzqq process here: https://drive.google.com/drive/folders/1Cm4egilB73kZLBm0nGLoKq8TrysQnkul?usp=sharing

Oh you have a lot of QED diagram.
They are likely irrelevant at the end of the day and I would be then worry about double counting with other weak process (especially ZZZ).

The presence of such diagram further compilcates the merging since all jet are not in double counting with the parton-shower due to the weak emission of jet. Additionally such contribution is likely to be small (please check) and very cpu intensive.

I would suggest to add QED<=2 flag during your generation.

Cheers,

Olivier

> On 14 Aug 2020, at 00:30, Jay Sandesara <email address hidden> wrote:
>
> Question #692360 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/692360
>
> Jay Sandesara gave more information on the question:
> Hey Olivier,
>
> So I managed to find the results.dat containing the end code error using
> a string search. Thanks!
>
> Apparently the error is stemming from the ggzzqq processes. Here are
> some of the errors found in the log.txt of failed jobs:
>
>
> Error: Failed despite same graph: 55
> STOP 4
> Have jets (>0) 0 0 0 0 0 1
> Should be
>
> Error: Failed despite same graph: 55
> STOP 4
> Have jets (>0) 0 0 0 0 0 0
> Should be 6
>
>
> And so on. They seem to be coming from directories named ./P0_gg_zzqq/G53_* where * goes from 1 to 8.
>
> What do you think?
>
> Thanks,
> Jay Sandesara
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Jay Sandesara (jaysandesara) said : #6

Thank you, I will give this a try!

In the meantime I was going through the diagrams for the pp->4lep+1jet process after reading your suggestion to see if I could perhaps reduce the computing time there by removing some diagrams. I noticed that there are (very few) diagrams with non-QCD jets. Look for example in the last page here: https://drive.google.com/file/d/1DtU4cCuyGIDWEhw6hWvpk9MLl8oQKyRC/view?usp=sharing

Would setting auto_ptj_mjj = True here be wrong or just somewhat inaccurate? Those are the only type of diagrams I could find with such jets. Unfortunately I missed these diagrams before and have generated events with auto_ptj_mjj = True.

When you have non QCD jet, this typically makes more sense to have
> auto_ptj_mjj = False
since you typically want to have a ptj on those jets which is independent of xqcut.
But in itself this is not wrong to keep this value on True.

Cheers,

Olivier

> On 14 Aug 2020, at 10:01, Jay Sandesara <email address hidden> wrote:
>
> Question #692360 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/692360
>
> Jay Sandesara posted a new comment:
> Thank you, I will give this a try!
>
> In the meantime I was going through the diagrams for the pp->4lep+1jet
> process after reading your suggestion to see if I could perhaps reduce
> the computing time there by removing some diagrams. I noticed that there
> are (very few) diagrams with non-QCD jets. Look for example in the last
> page here:
> https://drive.google.com/file/d/1DtU4cCuyGIDWEhw6hWvpk9MLl8oQKyRC/view?usp=sharing
>
> Would setting auto_ptj_mjj = True here be wrong or just somewhat
> inaccurate? Those are the only type of diagrams I could find with such
> jets. Unfortunately I missed these diagrams before and have generated
> events with auto_ptj_mjj = True.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Jay Sandesara (jaysandesara) said : #8

Hey Olivier,

Thanks for the explanation!

I reran the pp>zzjj using your recommendation of putting QED=2. After a fair amount of running, it ended up giving this log (note that I use MG v 2.7.2 for this):

INFO: P0_gg_zzgg/G1 is at 1.41e-07 +- 4.14e-08 pb. Now submitting iteration #2.
INFO: P0_gg_zzqq/G17 is at 0.00515 +- 0.00118 pb. Now submitting iteration #2.
INFO: P0_gg_zzqq/G16 is at 0.000189 +- 4.44e-05 pb. Now submitting iteration #2.
INFO: P0_gg_zzqq/G9 is at 0.000189 +- 2.86e-05 pb. Now submitting iteration #2.
Error when reading <open file '/scratch/jsandesara/MG5_aMC_v2_7_2/pp4lep2jetQED2/SubProcesses/P0_gg_zzqq/G26_1/results.dat', mode 'r' at 0x7feeae1261e0>
WARNING: 'file' object has no attribute 'rfind'
/scratch/jsandesara/MG5_aMC_v2_7_2/pp4lep2jetQED2/SubProcesses/survey.sh: line 17: 59996 Terminated ../madevent 2>&1 >> $k < input_app.txt
     59997 | tee -a $k

Again the issue seems to be coming from the ggzzqq processes. I went to the mentioned G26_* channels and got the following error in the log:

 RESET CUMULATIVE VARIABLE
 Error: Failed despite same graph: 29
 Have jets (>0) 0 0 0 0 1 0
 Should be

With the results.dat displaying:

end code not correct 4

The diagrams resulting from the QED=2 restriction can be found here: https://drive.google.com/drive/folders/1DCkJELc2ZGXe5CCGr2ciTAECytWU9Pfq?usp=sharing

It seems that this is also a merging issue, based on your previous explanation. Do you have any suggestions? I feel that this ggzzqq process is important for matching since it has ISR that could be double counted with parton shower jets. But is it possible to safely remove these diagrams if no other option is available?

Thanks,
Jay Sandesara

Jay Sandesara (jaysandesara) said : #9

For now I am retrying with

generate p p > z z g j QED=2 QCD=4 [noborn=QCD]

which however removes half of all diagrams. Please let me know if any other solution is possible. If such an issue can maybe be resolved by looser cuts, I can give it a try?

Thanks,
Jay Sandesara

Hi Jay,

Forcing a gluon in the final state is certainly a bad idea for the merging point of view. It would be much better to not include any two jet in the merging procedure than doing that.

Here is your options:
1. hack the code to bypass the crash, since this seems to be quite rare phase-space points. The error done should be under control since
  a. this seems to happen quite rarely
  b. this is related to a scale/parton history choice which is anyway a bit arbitrary
  c. If an impact is visible, one should be able to see issue on the DJR plot (and therefore should not pass validation
2. The second option is not use MLM, but use CKKW-L merging (and do not use the default dynamical scale choice of MG5aMC). Now I'm not an expert of CKKW-L merging especially for such type of complicated process.

Cheers,

Olivier

Jay Sandesara (jaysandesara) said : #11

Hey Olivier,

Thanks for the suggestions!

1. Yes, this sounds like a good idea. I will give this a try!

2. I have tried CKKW-L merging before, but it did not seem to work well and upon consultation with Stefan Prestel, he said that CKKW-L cannot handle loop induced processes and that new theoretical developments will be needed before it can handle them. (which will not happen anytime soon unfortunately)

Thanks,
Jay Sandesara

Jay Sandesara (jaysandesara) said : #12

Okay, so after running for about 105 hours, the 2 jet process crashed again, this time due to numerical instabilities associated with an event in the ggzzgg channel (which worked fine when generated individually). Heres the log:

INFO: P0_gg_zzgg/G8 is at 0.0118 +- 0.000858 pb. Now submitting iteration #5.
INFO: P0_gg_zzgg/G40.02 is at 0.000265 +- 2.35e-05 pb. Now submitting iteration #3.
WARNING: "One Event with large weight have been found (ratio = 6.22e+05) in channel G18 (with rel.contrib=0.00975).
This is likely due to numerical instabilities. The associated job is discarded to recover.
For offline investigation, the problematic discarded events are stored in:
/scratch/jsandesara/MG5_aMC_v2_7_2/pp4lep2jetQED2/SubProcesses/P0_gg_zzgg/DiscardedUnstableEvents
Start waiting for update. (more info in debug mode)
INFO: Idle: 51, Running: 80, Completed: 3750 [ 107h 2m ]
INFO: P0_gg_zzgg/G29.02 is at 0.0268 +- 0.00308 pb. Now submitting iteration #3.
INFO: P0_gg_zzgg/G42.02 is at 0.00382 +- 0.000626 pb. Now submitting iteration #3.
INFO: P0_gg_zzgg/G7 is at 0.277 +- 0.00973 pb. Now submitting iteration #5.
INFO: P0_gg_zzgg/G28.02 is at 0.0132 +- 0.00107 pb. Now submitting iteration #4.
WARNING: [Fail 5 times]
 [Errno 2] No such file or directory: '/scratch/jsandesara/MG5_aMC_v2_7_2/pp4lep2jetQED2/SubProcesses/P0_gg_zzgg/G18_1/results.dat'
/scratch/jsandesara/MG5_aMC_v2_7_2/pp4lep2jetQED2/SubProcesses/survey.sh: line 17: 374022 Terminated ../madevent 2>&1 >> $k < input_app.txt
     374023 | tee -a $k
INFO: Idle: 79, Running: 79, Completed: 3755 [ 107h 6m ]
/scratch/jsandesara/MG5_aMC_v2_7_2/pp4lep2jetQED2/SubProcesses/survey.sh: line 17: 374334 Terminated ../madevent 2>&1 >> $k < input_app.txt
     374335 | tee -a $k

I am attaching the discarded event, run card as well as the full G18_1 directory here: https://drive.google.com/drive/folders/1hcqLuedHsyWocpcS-IFPKpxPNmPL0Pbo?usp=sharing

The discarded event looks something like this:

<event>
 6 0 +8.7184290e+05 3.52121100e+02 7.54677100e-03 1.06174800e-01
       21 -1 0 0 502 501 +0.0000000000e+00 +0.0000000000e+00 +1.6262674031e+02 1.6262674031e+02 0.0000000000e+00 0.0000e+00 1.0000e+00
       21 -1 0 0 503 502 -0.0000000000e+00 -0.0000000000e+00 -3.9804777382e+02 3.9804777382e+02 0.0000000000e+00 0.0000e+00 -1.0000e+00
       23 1 1 2 0 0 +6.9033370773e+01 +1.4081351569e+01 -3.4143292986e+02 3.6035480805e+02 9.1188000000e+01 0.0000e+00 1.0000e+00
       23 1 1 2 0 0 +5.7269737213e+00 +1.1264771162e+00 +4.3217575560e+01 1.0107955956e+02 9.1188000000e+01 0.0000e+00 -1.0000e+00
       21 1 1 2 503 504 -5.0704920973e+01 -1.1217973012e+01 +4.8015384116e+01 7.0727003621e+01 0.0000000000e+00 0.0000e+00 -1.0000e+00
       21 1 1 2 504 501 -2.4055423522e+01 -3.9898556728e+00 +1.4778936679e+01 2.8513142907e+01 0.0000000000e+00 0.0000e+00 -1.0000e+00
<scales pt_clust_3="13000.00000" pt_clust_4="13000.00000" pt_clust_5="76.84712" pt_clust_6="6.32100"></scales>
<clustering>
<clus scale=" 6.321"> 5 6 -1 -1</clus>
<clus scale=" 76.847"> 1 5 2 -1</clus>
<clus scale=" 305.325"> 3 4 -1 -1</clus>
<clus scale=" 76.847"> 1 3 2 -1</clus>
</clustering>
</event>

And the end of the log in the g18 channel looks like this:

------------------------------------------------------------------------
| You are using CutTools - Version 1.9.3 |
| Authors: G. Ossola, C. Papadopoulos, R. Pittau |
| Published in JHEP 0803:042,2008 |
| http://www.ugr.es/~pittau/CutTools |
| |
| Compiler with 34 significant digits detetected |
 ----------------------------------------------------------------------

########################################################################
# #
# You are using OneLOop-3.6 #
# #
# for the evaluation of 1-loop scalar 1-, 2-, 3- and 4-point functions #
# #
# author: Andreas van Hameren <email address hidden> #
# date: 18-02-2015 #
# #
# Please cite #
# A. van Hameren, #
# Comput.Phys.Commun. 182 (2011) 2427-2438, arXiv:1007.4716 #
# A. van Hameren, C.G. Papadopoulos and R. Pittau, #
# JHEP 0909:106,2009, arXiv:0903.4665 #
# in publications with results obtained with the help of this program. #
# #
########################################################################
########################################################################
# #
# You are using OneLOop-3.6 #
# #
# for the evaluation of 1-loop scalar 1-, 2-, 3- and 4-point functions #
# #
# author: Andreas van Hameren <email address hidden> #
# date: 18-02-2015 #
# #
# Please cite #
# A. van Hameren, #
# Comput.Phys.Commun. 182 (2011) 2427-2438, arXiv:1007.4716 #
# A. van Hameren, C.G. Papadopoulos and R. Pittau, #
# JHEP 0909:106,2009, arXiv:0903.4665 #
# in publications with results obtained with the help of this program. #
# #
########################################################################
 Iteration 1 Mean: 0.4764E-01 Abs mean: 0.4764E-01 Fluctuation: 0.211E-02 0.342E+01 35.9%
  1 0.4764E-01 0.4764E-01 +- 0.2106E-02 2.80
 Relative summed weights:
  0.1000E+01 0.0000E+00
 Relative number of events:
  0.1000E+01 0.0000E+00
 Events:
        4000 0
 Accuracy: 0.000 0.020 0.044 0.000
 Finished due to accuracy 0.0000000000000000 2.0000000000000000E-002

 -------------------------------------------------------------------------------
 Accumulated results: Integral = 0.4764E-01
                        Std dev = 0.2106E-02
                       Cross sec = 0.4764E-01
             Chi**2 per DoF. = 0.0000
 -------------------------------------------------------------------------------
 Found 1744 events.
 Wrote 17 events.
 Events wgts > 1: 0
 % Cross section > 1: 0.0000000000000000 0.0000000000000000
-------------------------------------------------
---------------------------
 Results Last 1 iters: Integral = 0.4764E-01
                     Abs integral = 0.4764E-01
                          Std dev = 0.2106E-02
                  Chi**2 per DoF. = 0.0000
-------------------------------------------------
---------------------------
 Status 2.0000000000000000E-002 2 1

ls status:
events.lhe
ftn25
ftn26
grid_information
input_app.txt
log.txt
moffset.dat
results.dat
run1_app.log

Any suggestions?

Jay Sandesara (jaysandesara) said : #13

In the meantime I will rerun this on 2.7.3 to see if that works.

Jay Sandesara (jaysandesara) said : #14

Hey Olivier,

The process completed running and I find good DJR plots! See here: https://drive.google.com/drive/folders/1-EQsbWDqstUFyB0D9bt21YlaSHfhE2Kl?usp=sharing

I think this was a success. Thank you so much for helping out! The stats are low because the matching efficiency with 15 qCut was only about 5 % (98 out of 2k events).

Please let me know what you think as well of the DJR check?

I have one last question: I understand that MadSpin doesnt do spin correlations for loop induced processes. Do you happen to know of a program that can? Even if for the signal gg->H->ZZ samples where we have the simpler spin-0 Higgs?

Thanks,
Jay Sandesara

Jay Sandesara (jaysandesara) said : #15

Also, note that the crash I mentioned earlier with 2.7.2 didnt happen in 2.7.3 for some reason and the event generation was also quicker.

I'm confused about those DJR.

You seem to have a huge unphysical increase when you pass the QCUT value.
It seems 0/1jet sample are making nice transition but the 2 jet sample is not to my point of view.

Now you should plot the sum of the three curve this will be easier to evaluates if the curve is smooth or not.

Cheers,

Olivier

Jay Sandesara (jaysandesara) said : #17

Here it is:

https://drive.google.com/drive/folders/1jz6Pamlmj4yRISyJENqrhgX4eDNHrUDg?usp=sharing

I superimposed the sum of three curves. It is difficult to see the smoothness with low statistics in the 2 jet area, but it looks okay to me. What do you think?

Thanks,
Jay Snadesara

Jay Sandesara (jaysandesara) said : #18

The unphysical rise you mention, could that be due to low stats? The xsecs of the three processes after matching are as follows:

0 jet: 0.00044600 pb (1406/10k events passed)
1 jet: 0.00084540 pb (1258/20k events passed)
2 jet: 0.00161900 pb (98/2k events passed) (resulting in large uncertainties)

With the total: 0.0029104 pb matching the 0 jet showered xsec within 8% difference.

I have normalised the plots according to these cross sections using Rivet. Note that the matching is done using ATLAS' Athena framework and not directly using the MadGraph interface.

Please let me know if you need any more information. Or if you think this is inconclusive and we need to generate a higher stat sample for 2 jet to find out if everything is right?

Thanks,
Jay Sandesara

Hi,

> The unphysical rise you mention, could that be due to low stats?

Not impossible. In any case this analysis is useless if you do not have higher stats (otherwise I'm not sure to understand the point).

> 0 jet: 0.00044600 pb (1406/10k events passed)
> 1 jet: 0.00084540 pb (1258/20k events passed)
> 2 jet: 0.00161900 pb (98/2k events passed) (resulting in large uncertainties)

All efficiency are very very low.
You should consider to increase xqcut at generation time to increase such efficiency.
Be careful, putting that parameter too high can lead to bias but the lower you set it the lower efficiency you will have. xqcut to 5 seems very small in this case.

You also have no pt cut at all for all jet which are not part of the matching. Is this really what you want?

Cheers,

Olivierr

> On 6 Sep 2020, at 09:25, Jay Sandesara <email address hidden> wrote:
>
> Question #692360 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/692360
>
> Jay Sandesara posted a new comment:
> The unphysical rise you mention, could that be due to low stats? The
> xsecs of the three processes after matching are as follows:
>
> 0 jet: 0.00044600 pb (1406/10k events passed)
> 1 jet: 0.00084540 pb (1258/20k events passed)
> 2 jet: 0.00161900 pb (98/2k events passed) (resulting in large uncertainties)
>
> With the total: 0.0029104 pb matching the 0 jet showered xsec within 8%
> difference.
>
> I have normalised the plots according to these cross sections using
> Rivet. Note that the matching is done using ATLAS' Athena framework and
> not directly using the MadGraph interface.
>
> Please let me know if you need any more information. Or if you think
> this is inconclusive and we need to generate a higher stat sample for 2
> jet to find out if everything is right?
>
> Thanks,
> Jay Sandesara
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Jay Sandesara (jaysandesara) said : #20

Hey,

So let me clarify, this sample was generated so that we can have a working strategy that I can present and then get approval for central production of it in ATLAS. The high stats sample we then plan to use for several analyses, including systematics study and VBF analysis. For now, I just need enough stats to convince my colleagues that this is doable and the cuts are good.

I used auto_ptj_mjj = True when I generate the new 1,2 jet samples so all jets have a pt cut of at least 5 GeV.

I put xqcut = 5 and qCut = 15 initially following the lead of this paper (https://arxiv.org/pdf/2006.12860.pdf) which does a very similar generation (minus the s-channel higgs and using just the on-shell Z final states). I will try to use a higher xqcut, following your suggestion. I did try different qCuts for the 0,1 jet sample but following the statement in the MadGraph paper that qCut-xqcut should remain fixed for kT-MLM merging when scanning over qCuts. I found the 5,15 combo to be very good and things started getting bad from the 8,18 xqcut,qCut combo.

To increase sample size a bit, I put qCut to 10 in the 2 jet merged sample (xqcut still remains 5). See here: https://drive.google.com/drive/folders/1yjpSz7i0MmWLu5fWQwKpL-PYgPbBsW9e . Plots seem good. I also plotted 0,1,2 added sample and it looks very continous to me.

I will generate more events for this so we can get a better idea. Does this seem encouraging to you? Or should I drop this thing and start with a new xqcut value (or somehow without the hack you suggested)? It would be very helpful to have some input from you.

Thanks,
Jay Sandesara

Jay Sandesara (jaysandesara) said : #21

Upon further checking, we found that for the 0,1 jet sample, higher xqcut samples (8 GeV and 10 Gev) when I probe the 15 GeV qCut, I get more efficiency but worsening xsec agreement and discontinuos DJR plots. (slight for 8 GeV and much more pronounced for 10 GeV xqcut).

Indeed if qcut is set to 15, then you can not xqcut higher than 5.
Did you check if using higher value of qcut was working? the efficiency is so low (in top of a very slow MG5aMC in part due to the low cut) that checking if higher values for xqcut/qcut works.

I'm obviously not the one that you need to convince that such simulation makes sense but for me you have three issues to proof:
1) That you have the matching/merging well under control due to missing contribution in the parton-shower
2) That your setup pass the basic validation stage
3) That such simulation is worth in term of the ratio physics benefit/ cpu cost.

For 1, you have your paper ( I still have to read it to see if I agree with it).
For 2, you have the DJR plot, and your statement that it is flat (I'm a bit sceptical but ok)
For 3 you certainly need more stats to be able to convince anyone (at least me). In particular with such low stats, it is everything but clear on which observable you can show a gain in precision due to the 2j inclusion in the process.

Cheers,

Olivier

Can you help with this problem?

Provide an answer of your own, or ask Jay Sandesara for more information if necessary.

To post a message you must log in.