Error with 4-fermion interactions: failed to reduce to color indices

[Ilaria Brivio]

Hi,

I am having problems generating some processes with 4-fermion operators.
I am using the SMEFTsim UFO attached and I get errors when computing the interference term (the p contains b b~)

p p > t t~ b b~ NP^2==1

when four-quark operators with color singlet contractions are included. For instance this happens setting cud13x3x3x3 = 1 while leaving the other NP parameters to zero. (there's a restriction file in the UFO attached)

The event generation does not crash, but an error appears, referred to the channel with gg initial state. I could not find any other flag output in the folder, apart from a file named "error", which says just

 Error: failed to reduce to color indices: 1 0

I think that the UFO is ok, because the color contractions in the vertex (V_184) look ok, and also the same operators work with other processes. What can this be then?

Thanks a lot in advance,
Ilaria

[Olivier Mattelaer (olivier-mattelaer)]

Dear Ilaria,

I only reproduce your error when setting “dynamical_scale_choice” to -1 (which is the default).
But using the default dynamical scale choice is not really adapted to computation of interference.
This is what creates the real problem. I would suggest to either use a fix scale or a pure kinematical function for the scaled (i.e. having dynamical_scale_choice set to a positive number)

Cheers,

Olivier

> On Nov 16, 2017, at 19:17, Ilaria Brivio <email address hidden> wrote:
>
> Public bug reported:
>
> Hi,
>
> I am having problems generating some processes with 4-fermion operators.
> I am using the SMEFTsim UFO attached and I get errors when computing the interference term (the p contains b b~)
>
> p p > t t~ b b~ NP^2==1
>
> when four-quark operators with color singlet contractions are included.
> For instance this happens setting cud13x3x3x3 = 1 while leaving the
> other NP parameters to zero. (there's a restriction file in the UFO
> attached)
>
> The event generation does not crash, but an error appears, referred to
> the channel with gg initial state. I could not find any other flag
> output in the folder, apart from a file named "error", which says just
>
> Error: failed to reduce to color indices: 1 0
>
> I think that the UFO is ok, because the color contractions in the vertex
> (V_184) look ok, and also the same operators work with other processes.
> What can this be then?
>
> Thanks a lot in advance,
> Ilaria
>
> ** Affects: mg5amcnlo
> Importance: Undecided
> Status: New
>
> ** Attachment added: "ufo model with restriction"
> https://bugs.launchpad.net/bugs/1732756/+attachment/5010125/+files/SMEFTsim_tb1.tar.gz
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1732756
>
> Title:
> Error with 4-fermion interactions: failed to reduce to color indices
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hi,
>
> I am having problems generating some processes with 4-fermion operators.
> I am using the SMEFTsim UFO attached and I get errors when computing the interference term (the p contains b b~)
>
> p p > t t~ b b~ NP^2==1
>
> when four-quark operators with color singlet contractions are
> included. For instance this happens setting cud13x3x3x3 = 1 while
> leaving the other NP parameters to zero. (there's a restriction file
> in the UFO attached)
>
> The event generation does not crash, but an error appears, referred to
> the channel with gg initial state. I could not find any other flag
> output in the folder, apart from a file named "error", which says just
>
> Error: failed to reduce to color indices: 1 0
>
> I think that the UFO is ok, because the color contractions in the
> vertex (V_184) look ok, and also the same operators work with other
> processes. What can this be then?
>
> Thanks a lot in advance,
> Ilaria
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1732756/+subscriptions

[Ilaria Brivio (ilariab)]

Hi Olivier,

thanks for your answer! Actually I am still having trouble even changing the scale choice.

For instance, I am trying with dynamical_scale_choice = 2 and I still get an error with the process above if I set to 1 one among the parameters

cqd1Abs3333 cqu1Abs3333 cud1Abs3333 cuHAbs3x3

with all the other "c" coefficients to 0. Indeed I get an error with other combinations of parameters, but I think the bug is just the same for all of them. Also, the same parameters with other processes (e.g. with t t~ t t~ in final state) do not give any problem.

I have tried with dynamical_scale_choice = 1 and I get the same. So it looks like MG is behaving differently when I run it compared to what you get. Is there any log file or similar that can help understanding what is going on?

Thank you very much again!

Best,
Ilaria

[Olivier Mattelaer (olivier-mattelaer)]

Hi,

Did you use the restriction card?

If not this might be (be unlikely) explained by the fact that I’m running 2.6.1 (still in beta).
I do not think that it can explain the difference but maybe.

Cheers,

Olivier

> On Nov 27, 2017, at 16:18, Ilaria Brivio <email address hidden> wrote:
>
> Hi Olivier,
>
> thanks for your answer! Actually I am still having trouble even changing
> the scale choice.
>
> For instance, I am trying with dynamical_scale_choice = 2 and I still
> get an error with the process above if I set to 1 one among the
> parameters
>
> cqd1Abs3333 cqu1Abs3333 cud1Abs3333 cuHAbs3x3
>
> with all the other "c" coefficients to 0. Indeed I get an error with
> other combinations of parameters, but I think the bug is just the same
> for all of them. Also, the same parameters with other processes (e.g.
> with t t~ t t~ in final state) do not give any problem.
>
> I have tried with dynamical_scale_choice = 1 and I get the same. So it
> looks like MG is behaving differently when I run it compared to what you
> get. Is there any log file or similar that can help understanding what
> is going on?
>
> Thank you very much again!
>
> Best,
> Ilaria
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1732756
>
> Title:
> Error with 4-fermion interactions: failed to reduce to color indices
>
> Status in MadGraph5_aMC@NLO:
> Invalid
>
> Bug description:
> Hi,
>
> I am having problems generating some processes with 4-fermion operators.
> I am using the SMEFTsim UFO attached and I get errors when computing the interference term (the p contains b b~)
>
> p p > t t~ b b~ NP^2==1
>
> when four-quark operators with color singlet contractions are
> included. For instance this happens setting cud13x3x3x3 = 1 while
> leaving the other NP parameters to zero. (there's a restriction file
> in the UFO attached)
>
> The event generation does not crash, but an error appears, referred to
> the channel with gg initial state. I could not find any other flag
> output in the folder, apart from a file named "error", which says just
>
> Error: failed to reduce to color indices: 1 0
>
> I think that the UFO is ok, because the color contractions in the
> vertex (V_184) look ok, and also the same operators work with other
> processes. What can this be then?
>
> Thanks a lot in advance,
> Ilaria
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1732756/+subscriptions

[Ilaria Brivio (ilariab)]

Hi Olvier,

yes I am using the restriction card (I have one for each coefficient I switch on).
I can try modifying directly the param_card to see if it changes something..

Best,
Ilaria

[Ilaria Brivio (ilariab)]

Hi Olivier,

I "reopen" the thread because I noticed something more that may help solving this, hopefully!

When I launch the process I get a warning message that says
"P1_gg_ttxqq SubProcesses doesn't have available phase-space. Please check mass spectrum."
which is suspicious because there is definitely available phase-space for this process, I wouldn't see why not.

Then the generation crashes because the results.dat file for that subprocess is not found.

And simultaneously the "error" file I mentioned above gets produced.
I don't know what comes first, whether the color indices reduction or the phase space issue, but maybe this changes something?

I am using v.2.6.1 and I'm setting to 1 cqd1Abs3333 now, although I still get the same with 2.6.0 and with all the four-fermion operators that include 2 tops and have singlet color contraction.

Thanks again!
Ilaria

[Ilaria Brivio (ilariab)]

this is the restriction file I'm using.
All the light fermions, including the bottom, are massless.

[Ilaria Brivio (ilariab)]

I just discovered that the problem shows up not only with 4-fermion operators but also with dipole ones, for instance setting to 1 cuBAbs33 in the param_card.

The weird part is that this happens only for p p > t t~ b b~ but not for p p > t t~ t t~ or any other top process I have tried to generate.

I have the bottom massless and included in the proton definition.

[Olivier Mattelaer (olivier-mattelaer)]

Hi Ilaria,

I have investigated a similar problem for Gauthier.
The process is actually basically the same: d d~ > t > t t~ b b~ QED=0 NP^2==1
(in another model but this is pretty close).
The error he got is exactly the same one.
 Error: failed to reduce to colour indices: 1 0

This case is much simpler since thanks to not have any QED vertex and forcing to have a top in s-channel, they are only a single interference diagram. (which means that everything is clean and easy to check).

The problem is in the computation of the Leading-color computation in order to write correctly the events before passing those to the parton-shower. The problem is that the Leading colour contribution is taken from the SM diagram and that such term colour contribution is actually zero for the operator which act as a singlet colour exchange. Those colour being zero, madgraph tries to use the sub-leading colour but those have some internal inconsistency with the diagram consider (a gluon cannot be singlet at LC) and this can lead to such crash.

If you do not care about parton-shower, then an easy fix exists
(go to the file SubProcesses/addmothers.f and add a "return" statement at the beginning of the first routine of the file --after the declaration of variable obviously--).
Otherwise, I'm looking at one attempt of solution for the moment.

Cheers,

Olivier

[Olivier Mattelaer (olivier-mattelaer)]

Hi,

My current attempt to fix this is put here:
http://bazaar.launchpad.net/~mg5core1/mg5amcnlo/2.6.2/revision/287
(where you can find the patch if you want to give it a try).

Cheers,

Olivier

[Ilaria Brivio (ilariab)]

Hi,
I checked that modifying the addmothers.f works! I'll have a look at the patch now, thanks a lot!

Ilaria

[Ilaria Brivio (ilariab)]

Yep, the patch worked too!

Problem solved I would say.
Thanks a lot!

Ilaria