NLO VBF W+2jet production issues

Asked by Stephane Cooperstein on 2018-08-29

Hi,

I would like to produce at NLO in QCD a sample of EWK W+2jets production. I have prepared a proc_card.dat [1], following what was done to prepare a similar NLO EWK WW sample [2]. However when I run

./bin/mg5_aMC proc_card.dat

it seems to work fine, however during the output step it suddenly finishes too early without any error message [3]. I have rerun it and it "finishes" at exactly the same place, so I don't think it is just a random failure.

If anyone has any of ideas of what is going wrong here, or any suggestions for my implementation/workflow, any feedback would be very highly appreciated.

Thank you very much!
Stephane

[1] set complex_mass_scheme
import model loop_qcd_qed_sm_Gmu

define p = p b b~
define j = j b b~

define l+ = e+ mu+ ta+
define l- = e- mu- ta-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~

generate p p > l+ vl j j / t t~ h QED=4 QCD=0 [QCD]
add process p p > l- vl~ j j / t t~ h QED=4 QCD=0 [QCD]

output
launch

[2] https://arxiv.org/pdf/1803.07943.pdf

[3]
...
INFO: Generating Helas calls for FKS process: u~ c~ > ta- vt~ c~ d~ QED<=4 QCD=0 [ all = QCD ] / t t h (492 / 600)
INFO: Generating Helas calls for FKS process: u~ d~ > e- ve~ d~ d~ QED<=4 QCD=0 [ all = QCD ] / t t h (493 / 600)
INFO: Reusing existing color information for process: u~ d~ > e- ve~ d~ d~ QED<=4 QCD=0 [ all = QCD ] / t t h
INFO: Generating Helas calls for FKS process: u~ d~ > mu- vm~ d~ d~ QED<=4 QCD=0 [ all = QCD ] / t t h (494 / 600)
INFO: Generating Helas calls for FKS process: u~ d~ > ta- vt~ d~ d~ QED<=4 QCD=0 [ all = QCD ] / t t h (495 / 600)
INFO: Generating Helas calls for FKS process: u~ s~ > e- ve~ s~ d~ QED<=4 QCD=0 [ all = QCD ] / t t h (496 / 600)

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
marco zaro Edit question
Last query:
2018-08-29
Last reply:
2018-09-06
marco zaro (marco-zaro) said : #1

Hello Stephane,
can you try first with a stable W boson instead of e+ ve?
It may be that your problem is due to the memory being filled up, can you try to monitor the memory consumption?
In case, you can do
set low_mem_multicore_nlo_generation
before generating the process, which will switch to a more CPU and RAM efficient process generation
Let us know

Cheers,

Marco

Dear Marco,

Thank you very much for your prompt reply. I am not sure if it made a difference but I also took the liberty of updating to the latest version of Madgraph v2.6.3.2. Indeed the issue appears to be memory-related. Adding

set low_mem_multicore_nlo_generation

made a huge difference in the processing time! With stable W's it seems that everything works fine now (cool!), however once I require W -> l v it freezes again at some point before it is done. Any idea what else I can do?

Thank you very much,
Stephane

marco zaro (marco-zaro) said : #3

Hi Stephane,
unfortunately, I do not have much of a clue here, I need to investigate but
this may take some time.
In the meanwhile, if you can live with the stable W, then you can use
madspin to decay it.
Let me know.
cheers,
Marco

On Fri, Aug 31, 2018 at 5:07 PM Stephane Cooperstein <
<email address hidden>> wrote:

> Question #673120 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/673120
>
> Stephane Cooperstein posted a new comment:
> Dear Marco,
>
> Thank you very much for your prompt reply. I am not sure if it made a
> difference but I also took the liberty of updating to the latest version
> of Madgraph v2.6.3.2. Indeed the issue appears to be memory-related.
> Adding
>
> set low_mem_multicore_nlo_generation
>
> made a huge difference in the processing time! With stable W's it seems
> that everything works fine now (cool!), however once I require W -> l v
> it freezes again at some point before it is done. Any idea what else I
> can do?
>
> Thank you very much,
> Stephane
>
> --
> You received this question notification because you are subscribed to
> the question.
>

Hi Marco,

Thanks for your reply. Unfortunately if one includes only the on-shell W decays for this process the signal definition is no longer gauge invariant. Moreover the contribution from t-channel "peripheral" diagrams will not be included, which is a contribution at the 10-20% level. So I'm afraid that we will have to do it somehow in Madgraph. I still suspect the issue is memory related since it just freezes randomly long into running. Any suggestions for how I might further improve the memory usage or at least make it more robust to large memory usage?

Thanks again for your help,
Stephane

Can you help with this problem?

Provide an answer of your own, or ask Stephane Cooperstein for more information if necessary.

To post a message you must log in.