mssm: FR and V4 cross-chek

Asked by Arian Abrahantes

Dear MG-Team:

I obtained an awkward diagram counting while cross-checking different versions of MSSM in MG. I tried to narrow down chances by using the following input cards which happens to reproduce it:

import model_v4(model) mssm_v4(mssm)
define st = t1 t1~ t2 t2~
generate st > st g

Feynman diag counting of 4(6) for mssm_v4(mssm)

extra diagrams were associated to the gluon emission which changes squark mass eigenstate:

stop_1 -> stop_2 + g

I am not sure if this is a feature introduced by model author in MSSM FR (flipping mass eigenstate, taste like flavour changing current, loops atc... but it is not quite so). It looks like a bug to me. Since I am not an expert, I am posting it as a question and letting you know.

I tried for other squark flavour as:

define sq = ul ul~ ur ur~
generate sq > sq g

ad in those cases it looks fine, 4 diagrams regardless the model used

best regards,

arian

Question information

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

Hi Arian,

I forward your message to Benjamin Fuks which is the author of FR and of this particular model.
He is probably traveling today so it might take a bit of time for him to answer.

I have no idea if this vertex is allowed or not, I think it might be in general.
I have notice that the associate coupling is very small (for the sps1a point) so this doesn't really matter.

Cheers,

Olivier

On Sep 28, 2012, at 12:01 PM, Arian Abrahantes <email address hidden> wrote:

> New question #209845 on MadGraph5:
> https://answers.launchpad.net/madgraph5/+question/209845
>
> Dear MG-Team:
>
> I obtained an awkward diagram counting while cross-checking different versions of MSSM in MG. I tried to narrow down chances by using the following input cards which happens to reproduce it:
>
> import model_v4(model) mssm_v4(mssm)
> define st = t1 t1~ t2 t2~
> generate st > st g
>
> Feynman diag counting of 4(6) for mssm_v4(mssm)
>
> extra diagrams were associated to the gluon emission which changes squark mass eigenstate:
>
> stop_1 -> stop_2 + g
>
>
> I am not sure if this is a feature introduced by model author in MSSM FR (flipping mass eigenstate, taste like flavour changing current, loops atc... but it is not quite so). It looks like a bug to me. Since I am not an expert, I am posting it as a question and letting you know.
>
> I tried for other squark flavour as:
>
> define sq = ul ul~ ur ur~
> generate sq > sq g
>
> ad in those cases it looks fine, 4 diagrams regardless the model used
>
> best regards,
>
> arian
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Revision history for this message
Arian Abrahantes (arian-abrahantes) said :
#2

Dear Oliver:

I agree with you it is small coupling for a "rare" process. I'll wait for Mr. Fuks reply.

My concern is that I have a complex calculation where a single process has diagram counting of 400 or 560 depending on the model used and specifically. I am pretty sure interferences of such diagrams will alter my fnal results, though I can not assure it since computation is under way and it is time consuming. If I get a result a willl try to post it or send you or Mr. Fuks privately

thanks in advance,

arian

Revision history for this message
Best Benjamin Fuks (fuks) said :
#3

Dear Arian,

The vertex is indeed there, but if you look to its analytical expression, it is vanishing by means of unitarity of the stop mixing matrix. Therefore, even if you have six diagrams, not all of them are contributing to the width. You could for instance check that the numerical value of the width matches between the v4 model and the v5.

Since there is no mixing matrix for the other squarks, you don't have the issue you are mentioning.

Does this answer your question?

Regards,

Benjamin

Revision history for this message
Arian Abrahantes (arian-abrahantes) said :
#4

dear benjamin:

thanks for your reply. This is the answer I was looking for: the issue
spotted is a correct interpretation of the model which should vanish in
calculations.

However, this issue creates a second stressful situation: diagram count
will scale in complex calculations. For instance, in a reaction I am
studying diagrams count increase from 400 to 560 depending on the model
used: V4 or FR. In my case, a sort of 14 hour calculation in the former has
scaled up to 24 hour and counting in the latter and it must not give a
difference in the final result. I do not quite like that, neither my
cluster admin ;-)

As you said and I guessed this extra diagrams must have a null contribution
regardless reaction studied, however calculation time scales due to
meaningless diagrams. probably this is a question to MG experts, Is there
a way to prevent this vertex from appearing? Apparently, this is not the
documented case of selecting some diagrams to include in final calculation;
but removing a meaningless vertex. I know there is an open request from
spotting zero coupling vertex in a generation which I do not know if fits
this issue. Could it be possible that the mode itself take care of that?

A side note on this, on previous messages Olivier did some tests and the
coupling did not actually vanish I quote:"I have notice that the associate
coupling is very small (for the sps1a point) so this doesn't really
matter." So,
the coupling it is actually numerically assessed and not zero as expected.
After this, whether such artifact affects a calculation or not remains to
be tested. We are dealing with MSSM and results depends on SUSY
parameterizations which might change expected behaviors in similar sets of
diagrams. So I'll try to make some time to test this thoroughly because my
calculation depend on diagrams which happen to include such artifacts
which, in principle, must not affect the final result never. Unfortunately
my case of study, as noted above, does require computing power and such
vertex inclusion makes my calculation longer.

I hope I could provide more inputs on this issue during the following week.

thanks benjamin and olivier for your prompt reply,

best arian

On Sun, Sep 30, 2012 at 2:15 PM, Benjamin Fuks <
<email address hidden>> wrote:

> Your question #209845 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/209845
>
> Status: Open => Answered
>
> Benjamin Fuks proposed the following answer:
> Dear Arian,
>
>
> The vertex is indeed there, but if you look to its analytical expression,
> it is vanishing by means of unitarity of the stop mixing matrix. Therefore,
> even if you have six diagrams, not all of them are contributing to the
> width. You could for instance check that the numerical value of the width
> matches between the v4 model and the v5.
>
> Since there is no mixing matrix for the other squarks, you don't have
> the issue you are mentioning.
>
> Does this answer your question?
>
> Regards,
>
>
> Benjamin
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https://answers.launchpad.net/madgraph5/+question/209845/+confirm?answer_id=2
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/madgraph5/+question/209845
>
> You received this question notification because you asked the question.
>

Revision history for this message
Benjamin Fuks (fuks) said :
#5

Hello Arian,

Could you please provide us more information about your process? Otherwise, you can still try to suppress the problematic interaction by hand.

Cheers,

Benjamin

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

Hi,

In the short time, suppressing the interaction might be the best.
I will work on a way to remove this interactions automatically, but this is more a long term solution.

Cheers,

Olivier

On Sep 30, 2012, at 11:45 PM, Benjamin Fuks <email address hidden> wrote:

> Question #209845 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/209845
>
> Status: Open => Answered
>
> Benjamin Fuks proposed the following answer:
> Hello Arian,
>
>
> Could you please provide us more information about your process? Otherwise, you can still try to suppress the problematic interaction by hand.
>
> Cheers,
>
>
> Benjamin
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Revision history for this message
Arian Abrahantes (arian-abrahantes) said :
#7

dear olivier and benjamin:

I have performed a few test for clarifying the situation. I checked in a
faster event generation than my subject of study

import mssm
define sqt = t1 t1~ t2 t2~
generate g g > g > sqt sqt g

all diagrams with gt1t2 vertex has a null contribution to such events
xsection (I also checked its amplitude and squared amplitudes within
generated code). As suggested I removed manually such interaction vertices
from the MG-model resulting in a faster computation and identical values of
xsection were achieved. Such value agrees with mssm_v4 xsection computation
of that process.

The single problem left on this issue is the amount of trivial diagrams
amplitudes left to compute in the mssm default model. Especially in mssm
default model which happens to spend quite a lot of time in processes like:

gg_t1t2xg<file:///Users/arian/CERN/MG/MadGraph5_v1_4_7/mssm-sq-sqg/SubProcesses/P0_gg_t1t2xg/diagrams.html>

which is fully trivial as all its diagrams contains vertexes of the type
gt1t2 with null amplitude.

this is a simple generation but if you would try some process not very
fancy like:

generate p p > sqt sqt j

then diagram count:

mssm: 988 diagrams (316 independent)
mss-no-vertex-gsq1sq2: 338 diagrams (86 independent)

And that's really too much to handle for null contributions after all.

So I am almost sure now that my original reaction under study using mssm as
provide by MG will be identical to V4 although quite a lot of time spent in
the calculation already 48 hours and still counting, so I'll probably kill
it. I'll do as suggested by removing the vertexes waiting for long term
solution become available.

If there is something you'd like to test or code let me know, I could help.

best regards and thanks for your concern,

arian

On Mon, Oct 1, 2012 at 5:55 AM, Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #209845 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/209845
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> In the short time, suppressing the interaction might be the best.
> I will work on a way to remove this interactions automatically, but this
> is more a long term solution.
>
> Cheers,
>
> Olivier
>
>
> On Sep 30, 2012, at 11:45 PM, Benjamin Fuks <
> <email address hidden>> wrote:
>
> > Question #209845 on MadGraph5 changed:
> > https://answers.launchpad.net/madgraph5/+question/209845
> >
> > Status: Open => Answered
> >
> > Benjamin Fuks proposed the following answer:
> > Hello Arian,
> >
> >
> > Could you please provide us more information about your process?
> Otherwise, you can still try to suppress the problematic interaction by
> hand.
> >
> > Cheers,
> >
> >
> > Benjamin
> >
> > --
> > You received this question notification because you are a member of
> > MadTeam, which is an answer contact for MadGraph5.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https://answers.launchpad.net/madgraph5/+question/209845/+confirm?answer_id=5
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/madgraph5/+question/209845
>
> You received this question notification because you asked the question.
>

Revision history for this message
Arian Abrahantes (arian-abrahantes) said :
#8

Thanks Benjamin Fuks, that solved my question.