Fermion flow issue in the loops

Did you check the born/loop/real matrix-element with the check function?
If this is an issue related with the fermion flow it will likely spot the issue.

Cheers,

Olivier

Hi Olivier,

I directly ran
   check d d~ > s s~ NP=2 QCD=0 QED=0 [QCD]
   check d~ d > s s~ NP=2 QCD=0 QED=0 [QCD]
and the gauge test failed. It worked for some of the other subprocesses. What I don't understand and how it could work as the exact same vertices/counterterms are used all over the place. Any thoughts?

Cheers,

Benj

> On 13 Oct 2020, at 22:33 , Olivier Mattelaer <email address hidden> wrote:
>
> Did you check the born/loop/real matrix-element with the check function?
> If this is an issue related with the fermion flow it will likely spot the issue.
>
> Cheers,
>
> Olivier
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1899608
>
> Title:
> Fermion flow issue in the loops
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hi everyone,
>
> We are performing some new physics calculations in a model where the
> SM is extended by a squark (and an invisible state that is irrelevant
> for our purpose). The UFO is provided in attachment. The process of
> interest consists in dijet production. I use MG5_aMC 2.6.8 and as a
> process definition, I typed
>
> import model RPVMono_UFO_RG-paper
> set complex_mass_scheme True
> generate p p > j j NP=2 QCD=0 QED=0 [QCD]
> output
>
> In order to solely get QCD corrections to the new physics component, I have modified the madgraph/loop/loop_diagram_generation.py file. I have set the filtering to true (around l388)
> edit_filter_manually = True
> and then included
> loop_pdgs = [abs(x) for x in diag.get_loop_lines_pdgs()]
> is_loop_gluon = (21 in loop_pdgs)
> is_loop_sigma = (9000002 in loop_pdgs)
> if is_loop_sigma and not is_loop_gluon:
> valid_diag=False
> I get the needed diagrams (so that this works).
>
> However, when launching a cross section calculation, I get a pole non-cancellation issue. The weird thing is that poles are fine for the subprocesses
> d dbar to s sbar or s sbar to d dbar
> but not for the subprocess
> dbar d to s sbar
> This is weird as the diagrams are exactly the same. I suspect something problematic with the fermion flow here (as we have clashing arrows diagrams). Any thoughts?
>
> Cheers,
>
> Benj
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1899608/+subscriptions

Hi Olivier,

Any news here? Is there anything I could do on my side?

Cheers,

Benj

In my case when trying to generate tthose loops they fail to generate with:

Command "check d d~ > s s~ NP=2 QCD=0 QED=0 [QCD]" interrupted with error:
ValueError : -5 is not in list
Please report this bug on https://bugs.launchpad.net/mg5amcnlo
More information is found in 'MG5_debug'.
Please attach this file to your report.

Cheers,

Olivier

> On 16 Oct 2020, at 08:09, Benjamin Fuks <email address hidden> wrote:
>
> Hi Olivier,
>
> Any news here? Is there anything I could do on my side?
>
> Cheers,
>
> Benj
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1899608
>
> Title:
> Fermion flow issue in the loops
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hi everyone,
>
> We are performing some new physics calculations in a model where the
> SM is extended by a squark (and an invisible state that is irrelevant
> for our purpose). The UFO is provided in attachment. The process of
> interest consists in dijet production. I use MG5_aMC 2.6.8 and as a
> process definition, I typed
>
> import model RPVMono_UFO_RG-paper
> set complex_mass_scheme True
> generate p p > j j NP=2 QCD=0 QED=0 [QCD]
> output
>
> In order to solely get QCD corrections to the new physics component, I have modified the madgraph/loop/loop_diagram_generation.py file. I have set the filtering to true (around l388)
> edit_filter_manually = True
> and then included
> loop_pdgs = [abs(x) for x in diag.get_loop_lines_pdgs()]
> is_loop_gluon = (21 in loop_pdgs)
> is_loop_sigma = (9000002 in loop_pdgs)
> if is_loop_sigma and not is_loop_gluon:
> valid_diag=False
> I get the needed diagrams (so that this works).
>
> However, when launching a cross section calculation, I get a pole non-cancellation issue. The weird thing is that poles are fine for the subprocesses
> d dbar to s sbar or s sbar to d dbar
> but not for the subprocess
> dbar d to s sbar
> This is weird as the diagrams are exactly the same. I suspect something problematic with the fermion flow here (as we have clashing arrows diagrams). Any thoughts?
>
> Cheers,
>
> Benj
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1899608/+subscriptions

That's weird. Are you using the same version of mg5 as me (version 2.6.8)?

Cheers,

B>

> On 16 Oct 2020, at 09:33 , Olivier Mattelaer <email address hidden> wrote:
>
> In my case when trying to generate tthose loops they fail to generate
> with:
>
> Command "check d d~ > s s~ NP=2 QCD=0 QED=0 [QCD]" interrupted with error:
> ValueError : -5 is not in list
> Please report this bug on https://bugs.launchpad.net/mg5amcnlo
> More information is found in 'MG5_debug'.
> Please attach this file to your report.
>
> Cheers,
>
> Olivier
>
>> On 16 Oct 2020, at 08:09, Benjamin Fuks <email address hidden> wrote:
>>
>> Hi Olivier,
>>
>> Any news here? Is there anything I could do on my side?
>>
>> Cheers,
>>
>> Benj
>>
>> --
>> You received this bug notification because you are subscribed to
>> MadGraph5_aMC@NLO.
>> https://bugs.launchpad.net/bugs/1899608
>>
>> Title:
>> Fermion flow issue in the loops
>>
>> Status in MadGraph5_aMC@NLO:
>> New
>>
>> Bug description:
>> Hi everyone,
>>
>> We are performing some new physics calculations in a model where the
>> SM is extended by a squark (and an invisible state that is irrelevant
>> for our purpose). The UFO is provided in attachment. The process of
>> interest consists in dijet production. I use MG5_aMC 2.6.8 and as a
>> process definition, I typed
>>
>> import model RPVMono_UFO_RG-paper
>> set complex_mass_scheme True
>> generate p p > j j NP=2 QCD=0 QED=0 [QCD]
>> output
>>
>> In order to solely get QCD corrections to the new physics component, I have modified the madgraph/loop/loop_diagram_generation.py file. I have set the filtering to true (around l388)
>> edit_filter_manually = True
>> and then included
>> loop_pdgs = [abs(x) for x in diag.get_loop_lines_pdgs()]
>> is_loop_gluon = (21 in loop_pdgs)
>> is_loop_sigma = (9000002 in loop_pdgs)
>> if is_loop_sigma and not is_loop_gluon:
>> valid_diag=False
>> I get the needed diagrams (so that this works).
>>
>> However, when launching a cross section calculation, I get a pole non-cancellation issue. The weird thing is that poles are fine for the subprocesses
>> d dbar to s sbar or s sbar to d dbar
>> but not for the subprocess
>> dbar d to s sbar
>> This is weird as the diagrams are exactly the same. I suspect something problematic with the fermion flow here (as we have clashing arrows diagrams). Any thoughts?
>>
>> Cheers,
>>
>> Benj
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/mg5amcnlo/+bug/1899608/+subscriptions
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1899608
>
> Title:
> Fermion flow issue in the loops
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hi everyone,
>
> We are performing some new physics calculations in a model where the
> SM is extended by a squark (and an invisible state that is irrelevant
> for our purpose). The UFO is provided in attachment. The process of
> interest consists in dijet production. I use MG5_aMC 2.6.8 and as a
> process definition, I typed
>
> import model RPVMono_UFO_RG-paper
> set complex_...

The issue does not seem to come from the loop. But Benj is going to re-generate the model and check if the problem persist

Hi,
in case, please attach the check_poles.log file from the folder that fails.

Cheers,

Marco

> On 16 Oct 2020, at 11:58, Olivier Mattelaer <email address hidden> wrote:
>
> The issue does not seem to come from the loop. But Benj is going to re-
> generate the model and check if the problem persist
>
> ** Changed in: mg5amcnlo
> Status: New => Incomplete
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1899608
>
> Title:
> Fermion flow issue in the loops
>
> Status in MadGraph5_aMC@NLO:
> Incomplete
>
> Bug description:
> Hi everyone,
>
> We are performing some new physics calculations in a model where the
> SM is extended by a squark (and an invisible state that is irrelevant
> for our purpose). The UFO is provided in attachment. The process of
> interest consists in dijet production. I use MG5_aMC 2.6.8 and as a
> process definition, I typed
>
> import model RPVMono_UFO_RG-paper
> set complex_mass_scheme True
> generate p p > j j NP=2 QCD=0 QED=0 [QCD]
> output
>
> In order to solely get QCD corrections to the new physics component, I have modified the madgraph/loop/loop_diagram_generation.py file. I have set the filtering to true (around l388)
> edit_filter_manually = True
> and then included
> loop_pdgs = [abs(x) for x in diag.get_loop_lines_pdgs()]
> is_loop_gluon = (21 in loop_pdgs)
> is_loop_sigma = (9000002 in loop_pdgs)
> if is_loop_sigma and not is_loop_gluon:
> valid_diag=False
> I get the needed diagrams (so that this works).
>
> However, when launching a cross section calculation, I get a pole non-cancellation issue. The weird thing is that poles are fine for the subprocesses
> d dbar to s sbar or s sbar to d dbar
> but not for the subprocess
> dbar d to s sbar
> This is weird as the diagrams are exactly the same. I suspect something problematic with the fermion flow here (as we have clashing arrows diagrams). Any thoughts?
>
> Cheers,
>
> Benj
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1899608/+subscriptions

Hi Marco,

I have tried with a fresh UFO and nothing changes. The UFO seems to be therefore OK. The checks are the following:
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: P0_ddx_ssx
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: P0_dsx_dsx
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: P0_sd_sd
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: P0_sdx_sdx
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: P0_ssx_ddx
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for check_poles:
INFO: Poles successfully cancel for 20 points over 20 (tolerance=1.0e-05)
INFO: P0_dxd_ssx
INFO: Result for test_ME:
INFO: Passed.
INFO: Result for check_poles:
Error detected in "calculate_xsect "
write debug file /Users/fuks/Work/tools/madgraph/2.6.8/PROCNLO_RPVMono_UFO_RG-paper_7/run_03_tag_1_debug.log
If you need help with this issue please contact us on https://answers.launchpad.net/mg5amcnlo
aMCatNLOError : Poles do not cancel, run cannot continue

I will attach the last log below, since all the others are fine.

Hi Valentin,

After offline discussions on skype with Marco, it turns out that the issue is related to the treatment of the fermion flow in the loops. Therefore, I assign this issue to you :-)

If you want to treat it faster, feel free to contact me on skype.

Cheers,

Benj

PS: I have tested both with a fresh and with the old UFO (from our common 2015 paper), and both with 2.6.8 (python2) and 2.8.1 (python3). The problem is the same.

Hi Valentin,
Benjamin checked that when doing a standalone output of the virtuals, they return same born but different poles/finite part for
d d~ > s s~
and
d~ d > s s~.

I fear I can't help more than this....

Thanks!

Cheers,

Marco

Hi everyone,

Any news?

Cheers,

Benj

Hi everyone,

Has this been finally addressed?

Cheers,

Benj

Hi everyone,

After live discussions with Valentin, the following fix (that I shamelessly copy paste from Valentin's e-mail) solves it. Feel free to review it and merge it to the main branch.

Cheers,

Benj

<><><><><><><><><><>

We need to modify helas_objects.py (line 1349 in check_majorana_and_flip_flow) and replace the line

                new_wf = wavefunctions[wavefunctions.index(new_wf)]

by
                if (not new_wf.get('is_loop')) or (new_wf.get('pdg_code')>0):
                    index_wf = wavefunctions.index(new_wf)
                else:
                    for i_wf, wf in enumerate(wavefunctions):
                        if new_wf == wf and wf.get('pdg_code')==new_wf.get('pdg_code'):
                            index_wf = i_wf
                            break
                    else:
                        raise ValueError
                new_wf = wavefunctions[index_wf]

This is needed because for loop wavefunctions the recycling of external legs REQUIRES paying attention to the PDG code and not just the properties/charges of the particle:

            # When on the optimized output mode, the starting loop wavefunction
            # can be recycled if it has the same pdg because whatever its pdg
            # it has the same coefficients and loop momentum zero,
            # so it is in principle not necessary to add it to the
            # diagram_wavefunction. However, this is necessary for the function
            # check_and_fix_fermion_flow to correctly update the dependances of
            # previous diagrams to an external L-cut majorana wavefunction which
            # needs flipping.
            if not self.optimized_output:
                wavefunctionNumber=wavefunctionNumber+1
                external_loop_wf.set('number',wavefunctionNumber)
                diagram_wavefunctions.append(external_loop_wf)
            else:
                try:
                    external_loop_wf=\
                         external_loop_wfs_dict[external_loop_wf.get('pdg_code’)]