Reweighting semillptonic VBS problems

Hi,

In term of support, we only support the long term stable verstion (2.9.x) and the latest development version (3.3.1).
Older version of madgraph are not supported.

> The first question is:
> - Following previous threads [1], i understand that not all MG5 versions will work properly with the syntax above. Which version
> would you suggest to use in order to generate this process with decay chains reliably?

For the moment, I would say none official version are ensure to work reliably with decay chain if you have identical particle are different level of the decay.
If you look at version 2.8.0 release note you will see the following:
      OM: Adding new option in reweighting to allow the user to use the process_id in presence of ambiguous
          initial/final state.
Which can be use as a work-around to this issue in some cases (but not all cases)

However, we are currently thinking of implementing a support for such case in the 3.4.0, but this is currently under validation and this is not yet 100% clear which solution we will take. (either the average of the various possible permutation or the max).
currently the average is taken, but this will probably create a normalization issue in your case. Maybe doing the sum/max is better for this particular case: lp:~maddevelopers/mg5amcnlo/reweight_with_perm

>I need LO weights for 15 operators (136 reweight points). One way is to turn on all the 15 operators in the param card and use the reweight module to turn on and off the operators

I guess that you mean restrict_card not param_card here? the param_card should not impact the speed of the computation.
And according to my experience, computing "0" is quite well optimize by the compiler and the gain of speed is typically much smaller than the one that you expect.

> Is this behaviour expected for old MG5 versions? If not, is there a patch i can apply to those versions in order to make them work (i'd really like to stick to older versions of MG5 e.g. MG_2_6_5 if possible and reliable)?

If you speak about the name in the banner, they were indeed issue when used in conjunction with the reweight directory.
Additionally using multiple "change model" and the change rwgt_dir is something that we have never think about (and therefore tested). So this might also be a source of issue. For re-weighting, I strongly suggest to pass to 2.9.7(long term stable) since this is a functionallity that evolve quite a lot (and will do in the future too) and even by digging in the revision, they will be a lot of patches related to that functionality.

Cheers,

Olivier

Hi Olivier,

Thanks for the answer

> However, we are currently thinking of implementing a support for such case in the 3.4.0

That's good to know thanks.

> I guess that you mean restrict_card not param_card here? the param_card should not impact the speed of the computation.

yes restrict card indeed.

> And according to my experience, computing "0" is quite well optimize by the compiler and the gain of speed is typically much smaller than the one that you expect.

I find that generating the following process (same as above, just changing restriction) is impossible in terms of time, with version 2_6_5 and 2_6_7. Also reducing number of operators might not help (some of them drive the number of diagrams, cll1, cHl1 etc) :

[proc_card.dat]

set group_subprocesses Auto
set ignore_six_quark_processes False
set loop_optimized_output True
set complex_mass_scheme False
import model SMEFTsim_U35_MwScheme_UFO-cW_cHWB_cHDD_cHbox_cHW_cHl1_cHl3_cHq1_cHq3_cqq1_cqq11_cqq31_cqq3_cll_cll1_massless
define p = g u c d s b u~ c~ d~ s~ b~
define j = p
define l+ = e+ mu+ ta+
define l- = e- mu- ta-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~
generate j j > w- z j j QED=4 QCD=0 SMHLOOP=0 NP=1, w- > j j NP=1, z > l+ l- NP=1 @0 NP=1
output WmTo2JZToLL_MG267 --nojpeg
launch
set nevents 100

you can find the restrict card in [1] if you want to try.

> For re-weighting, I strongly suggest to pass to 2.9.7(long term stable) since this is a functionallity that evolve quite a lot (and will do in the future too) and even by digging in the revision, they will be a lot of patches related to that functionality.

Ok i will bear it in mind, thank you!

-----------------------------------------------------------------------------------------------------------------------------

[1]

http://gboldrin.web.cern.ch/gboldrin/generators/restrict_cW_cHWB_cHDD_cHbox_cHW_cHl1_cHl3_cHq1_cHq3_cqq1_cqq11_cqq31_cqq3_cll_cll1_massless.dat

Hi,

The time to generate X events and the time to reweight a sample are two quite different topic.
For generation of events it does make sense to use a restriction (since by doing that you help the intragator to minimize the number of evaluation), while for the re-weighting the impact should be much milder (since the number of evaluation is fixed)

This beind said 2.8.0 and even more 2.9.0 introduces huge speed-up in both the time to evaluate the matrix-element and in the phase-space integration (see 2102.00773 <https://arxiv.org/abs/2102.00773>) so if you have speed issue using 2.9.7 will also be benificial.

Now indeed all the smeftsim are typically huge (and messy) model and restriction will typically help a lot.

Cheers,

Olivier

> On 17 Dec 2021, at 18:15, Giacomo <email address hidden> wrote:
>
> Question #699906 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/699906
>
> Giacomo posted a new comment:
> Hi Olivier,
>
> Thanks for the answer
>
>> However, we are currently thinking of implementing a support for such
> case in the 3.4.0
>
> That's good to know thanks.
>
>> I guess that you mean restrict_card not param_card here? the
> param_card should not impact the speed of the computation.
>
> yes restrict card indeed.
>
>> And according to my experience, computing "0" is quite well optimize
> by the compiler and the gain of speed is typically much smaller than the
> one that you expect.
>
> I find that generating the following process (same as above, just
> changing restriction) is impossible in terms of time, with version 2_6_5
> and 2_6_7. Also reducing number of operators might not help (some of
> them drive the number of diagrams, cll1, cHl1 etc) :
>
> [proc_card.dat]
>
> set group_subprocesses Auto
> set ignore_six_quark_processes False
> set loop_optimized_output True
> set complex_mass_scheme False
> import model SMEFTsim_U35_MwScheme_UFO-cW_cHWB_cHDD_cHbox_cHW_cHl1_cHl3_cHq1_cHq3_cqq1_cqq11_cqq31_cqq3_cll_cll1_massless
> define p = g u c d s b u~ c~ d~ s~ b~
> define j = p
> define l+ = e+ mu+ ta+
> define l- = e- mu- ta-
> define vl = ve vm vt
> define vl~ = ve~ vm~ vt~
> generate j j > w- z j j QED=4 QCD=0 SMHLOOP=0 NP=1, w- > j j NP=1, z > l+ l- NP=1 @0 NP=1
> output WmTo2JZToLL_MG267 --nojpeg
> launch
> set nevents 100
>
> you can find the restrict card in [1] if you want to try.
>
>
>> For re-weighting, I strongly suggest to pass to 2.9.7(long term stable) since this is a functionallity that evolve quite a lot (and will do in the future too) and even by digging in the revision, they will be a lot of patches related to that functionality.
>
> Ok i will bear it in mind, thank you!
>
> -----------------------------------------------------------------------------------------------------------------------------
>
> [1]
>
> http://gboldrin.web.cern.ch/gboldrin/generators/restrict_cW_cHWB_cHDD_cHbox_cHW_cHl1_cHl3_cHq1_cHq3_cqq1_cqq11_cqq31_cqq3_cll_cll1_massless.dat
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Thank you Olivier for the useful clarifications.

Best,
Giacomo

Hi Olivier,
I was contacted by Pietro Govoni and Giacomo about this issue.
A quick question: about the permutation issue when one has the same particles in the production and decay process, can't the code use the mother/daughter information in the LHE file to identify the jets from the decay? (assuming one always writes the intermediate particles)
Cheers,

Marco

Hi Marco,

In theory yes, but they are many (really a lot) of corner cases that makes this difficult to handle in the correct way.
Like what do you do if zero mother are present? or worse how do you handle the case where two w mother is present.
I did started (three years ago) to build code which where using mother/daughter information and this blows up in complexity very quickly.

For 3.4.0, I would propose a much pragmatic approach where I would take the max (or the average) of the weight for the various permutation. Various person have confirmed that this is doing a good enough job. (if not then you should typically worried about the meaning of distinguish identical particle anyway)

Cheers,

Olivier