MG3.1.0 undershoots events for VBS ssWWjj LT and TL production

Asked by Karolos Potamianos on 2021-05-14

Hello,

I'm using the following script to produce a gridpack (using MG3.1.0 and running with LCG_99-x86_64-centos7-gcc10-opt) to generate LT-polarised ssWWjj VBS events:

generate p p > w+{0} w+{T} j j QCD=0, w+ > l+ vl, w+ > l+ vl @0
add process p p > w-{0} w-{T} j j QCD=0, w- > l- vl~ @0
add process p p > w+{T} w+{0} j j QCD=0, w+ > l+ vl, w+ > l+ vl @0
add process p p > w-{T} w-{0} j j QCD=0, w- > l- vl~ @0
output PROC_ssWWjj_EW_LTTL
launch
  set hard_survey 1
  set nevents 0
  set gridpack True
  set use_syst False

However, when extracting the gridpack, and running

./run.sh 10000 randomSeed 1

For each job, the seed is randomSeed=$(( ${ClusterId} + ${ProcId} )) where the ProcId and ClusterId are respectively the last and 1-before-last items in the list below. (e.g. ClusterId=2353020 and ProcId=9 in the file LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-9.lhe.gz)

I get the follwing event count in the LHE produced files:

LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-0.lhe.gz:2571
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-1.lhe.gz:37
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-2.lhe.gz:2828
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-3.lhe.gz:1034
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-4.lhe.gz:810
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-5.lhe.gz:1634
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-6.lhe.gz:617
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-7.lhe.gz:1788
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-8.lhe.gz:808
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-9.lhe.gz:50
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-0.lhe.gz:37
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-1.lhe.gz:2828
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-2.lhe.gz:1034
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-3.lhe.gz:810
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-4.lhe.gz:1634
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-5.lhe.gz:617
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-6.lhe.gz:1788
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-7.lhe.gz:808
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-8.lhe.gz:50
LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-9.lhe.gz:80

As you can see we're very far from 10k events. I thought that setting hard_survey 1 was meant to help in such cases (cf https://answers.launchpad.net/mg5amcnlo/+question/693332).

Generation of {0}{0} and {T}{T} events seems to work fine. I haven't yet tested separating {0}{T} and {T}{0}, or the charges, nor using different @x process identifiers. These are on my to-do but I would be surprised if they helped.

Could you please let me know if there's something I can do to obtain more events per run ? Also, is it safe to nevertheless combine these events or am I biasing the distributions ?

I am happy to run further tests you might suggest if that helps.

Thanks a lot.

Best,
Karolos

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

What is the value of sde_strategy that was used in that case?

Typically the fully longitudinal case is the most complex one and this is the one we studied in
2102.00773 <https://arxiv.org/abs/2102.00773> I would suggest to look at that paper which contains a lot of study/parameter to tweak the phase-space integration and (hopefully) have a better setting.

Cheers,

Olivier

> On 14 May 2021, at 15:55, Karolos Potamianos <email address hidden> wrote:
>
> New question #697056 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/697056
>
> Hello,
>
> I'm using the following script to produce a gridpack (using MG3.1.0 and running with LCG_99-x86_64-centos7-gcc10-opt) to generate LT-polarised ssWWjj VBS events:
>
> generate p p > w+{0} w+{T} j j QCD=0, w+ > l+ vl, w+ > l+ vl @0
> add process p p > w-{0} w-{T} j j QCD=0, w- > l- vl~ @0
> add process p p > w+{T} w+{0} j j QCD=0, w+ > l+ vl, w+ > l+ vl @0
> add process p p > w-{T} w-{0} j j QCD=0, w- > l- vl~ @0
> output PROC_ssWWjj_EW_LTTL
> launch
> set hard_survey 1
> set nevents 0
> set gridpack True
> set use_syst False
>
> However, when extracting the gridpack, and running
>
> ./run.sh 10000 randomSeed 1
>
> For each job, the seed is randomSeed=$(( ${ClusterId} + ${ProcId} )) where the ProcId and ClusterId are respectively the last and 1-before-last items in the list below. (e.g. ClusterId=2353020 and ProcId=9 in the file LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-9.lhe.gz)
>
> I get the follwing event count in the LHE produced files:
>
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-0.lhe.gz:2571
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-1.lhe.gz:37
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-2.lhe.gz:2828
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-3.lhe.gz:1034
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-4.lhe.gz:810
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-5.lhe.gz:1634
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-6.lhe.gz:617
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-7.lhe.gz:1788
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-8.lhe.gz:808
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353019-9.lhe.gz:50
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-0.lhe.gz:37
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-1.lhe.gz:2828
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-2.lhe.gz:1034
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-3.lhe.gz:810
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-4.lhe.gz:1634
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-5.lhe.gz:617
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-6.lhe.gz:1788
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-7.lhe.gz:808
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-8.lhe.gz:50
> LCG_99-x86_64-centos7-gcc10-opt-events-10000-1-2353020-9.lhe.gz:80
>
> As you can see we're very far from 10k events. I thought that setting hard_survey 1 was meant to help in such cases (cf https://answers.launchpad.net/mg5amcnlo/+question/693332).
>
> Generation of {0}{0} and {T}{T} events seems to work fine. I haven't yet tested separating {0}{T} and {T}{0}, or the charges, nor using different @x process identifiers. These are on my to-do but I would be surprised if they helped.
>
> Could you please let me know if there's something I can do to obtain more events per run ? Also, is it safe to nevertheless combine these events or am I biasing the distributions ?
>
> I am happy to run further tests you might suggest if that helps.
>
> Thanks a lot.
>
> Best,
> Karolos
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Karolos Potamianos (karolos-potamianos) said :
#2

Hello Olivier,

Thanks for your quick response. All what I changed is in the script above. Thus, the default sde_strategy value is 2.

I wasn't aware of the paper; very interesting. Thanks for pointing it out. I will read it carefully but from a quick skimming I suppose that you suggest to tweak the parameters sde_strategy, hard_survey and second_refine_threshold. I will try that out.

Cheers,
Karolos

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#3

> Thanks for your quick response. All what I changed is in the script
> above. Thus, the default sde_strategy value is 2.

The default are not universal within MG5aMC, depending of the process that you generate the default value for many parameter will change. So it is nice that you checked that this is indeed the default for that process.

> I wasn't aware of the paper; very interesting. Thanks for pointing it
> out. I will read it carefully but from a quick skimming I suppose that
> you suggest to tweak the parameters sde_strategy, hard_survey and
> second_refine_threshold. I will try that out.

Here i was more thinking about the t channel ordering of the paper (option -1 and -2)

Otherwise they are two un-documented option that you might want to try:
1) in the optional block of the run_card "psoptim" that you can display via the command
update psoptim

you have the parameter:
> -1.0 = tmin_for_channel ! limit the non-singular reach of --some-- channel of integration related to T-channel diag\
> ram (value between -1 and 0), -1 is no impact

Value of ~ -0.4 can sometimes improves the situation. However that parameter is not 100% safe since it can also act as a real cut if a given T-channel propagator is present in all Feynman Diagram

2) you also have the global option
set max_t_for_channel X
that you need to set before the generation of the diagram.
You can check with X=2 and with X=3 to see if you improve the situation.

Cheers,

Olivier

> On 14 May 2021, at 23:30, Karolos Potamianos <email address hidden> wrote:
>
> Question #697056 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697056
>
> Karolos Potamianos posted a new comment:
> Hello Olivier,
>
> Thanks for your quick response. All what I changed is in the script
> above. Thus, the default sde_strategy value is 2.
>
> I wasn't aware of the paper; very interesting. Thanks for pointing it
> out. I will read it carefully but from a quick skimming I suppose that
> you suggest to tweak the parameters sde_strategy, hard_survey and
> second_refine_threshold. I will try that out.
>
> Cheers,
> Karolos
>
> --
> 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 Karolos Potamianos for more information if necessary.

To post a message you must log in.