vanishing cross-section for light quarks in custom UFO process

Dear Otilia, Lucien and Julien,

It is very difficult to make any statement on how the model is handle without having the model.
But if the model defines a mass for the light quark then that particle will be treated as massive by MadGraph.

On the other hand, if the model set the mass for some particle to zero, then MG will make a specific treatment for those particles.
(Different propagator and the possibility to merge different final state as long as they are all massless).
So I would suggest that you check in your model if the mass of the light quark is set to zero or not.

> If you don't mind, an extra (unrelated) question: it was stated by Olivier in one of the threads, that most of the cuts in run_card.dat are ignored when running to compute decay widths. Is it possible to know (or be pointed to a reference) which ones, if any, are kept? For example, are pT and angular separation between patrons available?

All the cuts above the following comment:
# Inclusive cuts
Should not be working while the one below that statement should be working as usual.

Cheers,

Olivier

On Sep 12, 2014, at 7:37 PM, Julien Maurer <email address hidden> wrote:

> New question #254411 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/254411
>
> Dear experts,
>
>
> We're playing with a custom UFO model, that features a new vector boson coupling only to gluons.
> We encounter a curious behaviour:
>
> Computing decay widths of this new boson in channels involving quarks, we get non-zero and good-looking results. For example:
> generate X > g u u~
> generate X > g t t~
> etc
> [These decays proceed by a virtual gluon connecting on one side to the vector boson and the other outgoing gluon, and on the other side to the quark pair. For completeness the decay width for the first case is about one order of magnitude above the one for tops. ]
>
> If now we want instead to look at production of these same final states, but through mediation of a s-channel "new boson":
> generate g g > X > g u u~
> generate g g > X > g t t~
>
> The first case (with up quarks) complains about a vanishing cross-section, whereas the second case (with top quarks) proceeds fine with the computation and returns a non-zero cross-section. Trying with other flavours, only b quarks yield valid results, so the problem occurs for the 4 lightest quarks. Other types of channels show the same behaviour (issues with light quarks, valid with 3rd generation quarks).
> Discarding the obvious: mass, width and coupling are set to reasonable values (same as those used for the working decay width computation, actually). Note also that there is nothing in the model that would add some distinction between quarks, beyond what is featured in the SM.
>
> Would you have any idea, a difference of treatment between light and heavier quarks, that may cause this behaviour?
>
> For example, are light quarks treated as massless at some stage of the computation (don't know if it can explain the vanishing cross-section but that would be a clue, at least)? They are not massless in the param_card. We tried to set some even higher masses (50 GeV), but with the same result.
>
>
> If you don't mind, an extra (unrelated) question: it was stated by Olivier in one of the threads, that most of the cuts in run_card.dat are ignored when running to compute decay widths. Is it possible to know (or be pointed to a reference) which ones, if any, are kept? For example, are pT and angular separation between partons available?
>
>
> Thanks a lot,
> Otilia, Lucien and Julien
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

  Dear Olivier,

Thanks a lot for your fast answer... We are of course realizing it's hard for you to tell without the model (which is, actually, a very simple add-on to FeynRule' Standard Model, that doesn't modify the quark sector). We just wanted to see if you had heard of this kind of issues already. Apparently not, so we'll try to investigate deeper the model...
And, thank you for the precision about the cuts!

Cheers,
Otilia, Lucien and Julien

  Dear Olivier,

Sorry to come back to this thread... Actually Lucien figured out that changing 'maxjetflavor' from 4 to 0 allows the cross-section to be computed properly. However, if we leave it to 4 and set all the default cuts for light jets in run_card to match those for b-jets, the cross-section still vanishes. As a cross-check if we disable all the cuts (F = cut_decays) the problem remains. So it's not about the cuts.

Hence, it seems that the parameter 'maxjetflavor' is used for other purposes than the choice of the cuts... and has some unwanted impact on our cross-section computation. Any idea about what could cause the issue?

Note that we don't have ME/PS matching enabled.

Cheers,
Otilia, Lucien and Julien

Dear Julien, Otilia, Lucien,

Could you send me the model by email? <email address hidden>.
The only idea that I have right now is a problem related to the scale choice for your process but this should not be a problem for a X mass above 2*m_top.

> As a cross-check if we disable all the cuts (F = cut_decays) the problem remains. So it's not about the cuts.

This is actually not a good cross-check since you do not have decay in this case (you do not ask for an onshell X)
this parameter is use for the following syntax:
g g > X, X > g u u~
Please look at https://cp3.irmp.ucl.ac.be/projects/madgraph/attachment/wiki/MGTalks/13_06_10_tutomg_tasi.pdf
for details on the difference between the two syntax.

Cheers,

Olivier

Perfect! Thanks a lot for your investigations!

Cheers,
Otilia, Lucien and Julien

Thanks Olivier Mattelaer, that solved my question.