MadGraph5_aMC@NLO

unrestricted Standard Model

Asked by Arian Abrahantes

Dear MG-Team:

I am trying to make a generation of processes in a the most general SM available in MG5. therefore I use the following command:

import model sm-full

it loads all CKM related couplings (qq'Q, I checked that the coupling are built with all CKM matrix elements) and adds the s-s-H and c-c-H couplings. However it does not include the yukawa coupling of Higgs boson to first generation fermions (i.e. u-u-H, d-d-H may be as relevant for my calculation as the included s-s-H or at least I was asked to check it explicitly).

1- Is there a way to customize that part of the model or force Madraph to take u-u-H and d-d-H into account for generating the diagrams?

or

will I have to obviate those contributions by "physical reasons" (take as a fact that yukawa coupling of higgs to first generation is too small to be taken into account )

2 - In the new generation of diagrams (in the full SM) I can see diagrams with the s-s-H and c-c-H couplings however in the logs of the calculation I notice that the yukawa couplings related to them are not printed (at least explicitly, may be there is no "ys" parameter defined ) is there a way to know if the couplings in the s-s-H are used (not set to zero at calculation time).

Cheers and thanks in advance,

arian

PS: I am aware of this

https://answers.launchpad.net/madgraph5/+question/227415

but it seems that customization makes sense for a restricted model (as loaded by "import model sm" which a restricted class of SM.)

Question information

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

Hi Arian,

Indeed even in sm-full, the mass of the u, d, s are assume to be zero.
and the associate interactions to the Higgs has been neglected.
For LHC physics, I doubt about the necessity to include the mass of any of those quarks.
the mass of the quarks are completely negli geable compare to the energy of the parton.

> 1- Is there a way to customize that part of the model or force Madraph to take u-u-H and d-d-H into account for generating the diagrams?

One way is to ue FR to generate the new model:
http://feynrules.irmp.ucl.ac.be/wiki/StandardModel
if you don't apply any restrictions, those masses are preserved.
You can also modified the UFO Model by hand but this is a bit tedious.

> will I have to obviate those contributions by "physical reasons" (take as a fact that yukawa coupling of higgs to first generation is too small to be taken into account )

See above, but this depends of course of your exact study/scale

> 2 - In the new generation of diagrams (in the full SM) I can see diagrams with the s-s-H and c-c-H couplings however in the logs of the calculation I notice that the yukawa couplings related to them are not printed (at least explicitly, may be there is no "ys" parameter defined ) is there a way to know if the couplings in the s-s-H are used (not set to zero at calculation time).

I have made a run (p p > c c~)
and I see the following in the file: SubProcesses/P0_gg_ccx/G2/run_01_log.txt

 ymc = 1.2699999809265137
 ymb = 4.1999998092651367
 ymt = 164.50000000000000

and latter:

 lam = 0.11876576810517753
 yb = 2.41236856814812176E-002
 yc = 7.29454327301954069E-003
 ye = 2.93504850670934038E-006
 ym = 6.06883028478528356E-004
 yt = 0.94484439876629223

So, you have yc as expected but not ys since they are not h s s~ interactions ( at least I don't have it in my version of the model, so I'm surprised that you have it)

Cheers,

Olivier

On Sep 30, 2013, at 1:16 PM, Arian Abrahantes <email address hidden> wrote:

> New question #236606 on MadGraph5:
> https://answers.launchpad.net/madgraph5/+question/236606
>
> Dear MG-Team:
>
> I am trying to make a generation of processes in a the most general SM available in MG5. therefore I use the following command:
>
> import model sm-full
>
> it loads all CKM related couplings (qq'Q, I checked that the coupling are built with all CKM matrix elements) and adds the s-s-H and c-c-H couplings. However it does not include the yukawa coupling of Higgs boson to first generation fermions (i.e. u-u-H, d-d-H may be as relevant for my calculation as the included s-s-H or at least I was asked to check it explicitly).
>
> 1- Is there a way to customize that part of the model or force Madraph to take u-u-H and d-d-H into account for generating the diagrams?
>
> or
>
> will I have to obviate those contributions by "physical reasons" (take as a fact that yukawa coupling of higgs to first generation is too small to be taken into account )
>
> 2 - In the new generation of diagrams (in the full SM) I can see diagrams with the s-s-H and c-c-H couplings however in the logs of the calculation I notice that the yukawa couplings related to them are not printed (at least explicitly, may be there is no "ys" parameter defined ) is there a way to know if the couplings in the s-s-H are used (not set to zero at calculation time).
>
> Cheers and thanks in advance,
>
> arian
>
>
> PS: I am aware of this
>
> https://answers.launchpad.net/madgraph5/+question/227415
>
>
> but it seems that customization makes sense for a restricted model (as loaded by "import model sm" which a restricted class of SM.)
>
> --
> 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

Thanks Olivier Mattelaer, that solved my question.

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

Hi Olivier:

indeed I misscounted generated diagrams in some of my processes: s-s-H, u-u-H, d-d-H couplings are switched off in the "sm-full" import choice.

Regarding to FR model generation, either my Mathematica (version 6) or OS (MacOsX 10.5.8) are not compatible with FeynRules version (1.6 or new beta version previous to 1.8). MadGraphv4 output works well but something crashed in the UFO model generation. At the very end of the FR1.6 -stable version-, after computing all vertices and couplings of the SM Lagrangian, this is the log in Mathematica.

WriteUFO[LGauge, LHiggs, LFermions, LYukawa];

General::stop: Further output of Part::partd will be suppressed during this calculation. >>
Take::normal: Nonatomic expression expected at position 1 in Take[False,{2,2}]. >>
Take::normal: Nonatomic expression expected at position 1 in Take[False,{2,2}]. >>
Take::normal: Nonatomic expression expected at position 1 in Take[False,{2,2}]. >>
General::stop: Further output of Take::normal will be suppressed during this calculation. >>
First::normal: Nonatomic expression expected at position 1 in First[Multpad]. >>
First::argx: First called with 0 arguments; 1 argument is expected. >>
First::argx: First called with 0 arguments; 1 argument is expected. >>
First::normal: Nonatomic expression expected at position 1 in First[Multpad]. >>
Take::argm: Take called with 0 arguments; 1 or more arguments are expected. >>
Take::argm: Take called with 0 arguments; 1 or more arguments are expected. >>
First::normal: Nonatomic expression expected at position 1 in First[Multpad]. >>
General::stop: Further output of First::normal will be suppressed during this calculation. >>
First::argx: First called with 0 arguments; 1 argument is expected. >>
General::stop: Further output of First::argx will be suppressed during this calculation. >>
Take::argm: Take called with 0 arguments; 1 or more arguments are expected. >>
General::stop: Further output of Take::argm will be suppressed during this calculation. >>
Function::slotn: Slot number 1 in {PRIVATE`CouplingObject[#1]}& cannot be filled from ({PRIVATE`CouplingObject[#1]}&)[]. >>
Function::slotn: Slot number 1 in {PRIVATE`CouplingObject[#1]}& cannot be filled from ({PRIVATE`CouplingObject[#1]}&)[]. >>
Function::slotn: Slot number 1 in {PRIVATE`CouplingObject[#1]}& cannot be filled from ({PRIVATE`CouplingObject[#1]}&)[]. >>
General::stop: Further output of Function::slotn will be suppressed during this calculation. >>
Transpose::nmtx: The first two levels of the one-dimensional list {{First[],First[1]},<<22>>[<<1>>,<<1>>],{{PRIVATE`CouplingObject[#1]},{<<22>>[False]}}} cannot be transposed. >>
Transpose::nmtx: The first two levels of the one-dimensional list {{First[],First[1]},<<22>>[<<1>>,<<1>>],{{PRIVATE`CouplingObject[#1]},{<<22>>[False]}}} cannot be transposed. >>
Transpose::nmtx: The first two levels of the one-dimensional list {{First[],First[1]},<<22>>[<<1>>,<<1>>],{{PRIVATE`CouplingObject[#1]},{<<22>>[False]}}} cannot be transposed. >>
General::stop: Further output of Transpose::nmtx will be suppressed during this calculation. >>
Join::heads: Heads List and PRIVATE`PrependToLines at positions 1 and 2 are expected to be the same. >>
Join::heads: Heads List and PRIVATE`PrependToLines at positions 1 and 2 are expected to be the same. >>
Join::heads: Heads List and PRIVATE`PrependToLines at positions 1 and 2 are expected to be the same. >>
General::stop: Further output of Join::heads will be suppressed during this calculation. >>
Transpose::list: List expected at position 2 in Transpose[{{\!\(\*OverscriptBox[\"b\", \"\\\"\<-\>\\\"\"]\),1},{b,2},{A,3}},Join[<<1>>]]. >>
Transpose::list: List expected at position 2 in Transpose[{{\!\(\*OverscriptBox[\"c\", \"\\\"\<-\>\\\"\"]\),1},{c,2},{A,3}},Join[<<1>>]]. >>
Transpose::list: List expected at position 2 in Transpose[{{\!\(\*OverscriptBox[\"d\", \"\\\"\<-\>\\\"\"]\),1},{d,2},{A,3}},Join[<<1>>]]. >>
General::stop: Further output of Transpose::list will be suppressed during this calculation. >>
    - Optimizing: 139/139 .
Transpose::argt: Transpose called with 0 arguments; 1 or 2 arguments are expected. >>
MapAt::partw: Part {2} of #2 does not exist. >>
Transpose::argt: Transpose called with 0 arguments; 1 or 2 arguments are expected. >>
Transpose::argt: Transpose called with 0 arguments; 1 or 2 arguments are expected. >>
General::stop: Further output of Transpose::argt will be suppressed during this calculation. >>
    - Writing files.
StringJoin::string: String expected at position 2 in L.<>MapAt[PRIVATE`OptimizeIndexName,#2,2].
StringJoin::string: String expected at position 2 in C.<>#3.
StringJoin::string: String expected at position 1 in StringJoin[PYDicEntry[(0,0),C.<>#3]].
General::stop: Further output of StringJoin::string will be suppressed during this calculation. >>
Done!

Thus nothing to say, I had to implement the couplings/vertices/parameter python files by hand, boring but "doable" I am already calculating.

cheers,

arian

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

Hi Arian,

Please contact the FR author on that. I'm not qualified for such questions.

Cheers,

Olivier

On Oct 1, 2013, at 9:21 AM, Arian Abrahantes <email address hidden> wrote:

> Question #236606 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/236606
>
> Arian Abrahantes posted a new comment:
> Hi Olivier:
>
> indeed I misscounted generated diagrams in some of my processes: s-s-H,
> u-u-H, d-d-H couplings are switched off in the "sm-full" import choice.
>
>
> Regarding to FR model generation, either my Mathematica (version 6) or OS (MacOsX 10.5.8) are not compatible with FeynRules version (1.6 or new beta version previous to 1.8). MadGraphv4 output works well but something crashed in the UFO model generation. At the very end of the FR1.6 -stable version-, after computing all vertices and couplings of the SM Lagrangian, this is the log in Mathematica.
>
> WriteUFO[LGauge, LHiggs, LFermions, LYukawa];
>
> General::stop: Further output of Part::partd will be suppressed during this calculation. >>
> Take::normal: Nonatomic expression expected at position 1 in Take[False,{2,2}]. >>
> Take::normal: Nonatomic expression expected at position 1 in Take[False,{2,2}]. >>
> Take::normal: Nonatomic expression expected at position 1 in Take[False,{2,2}]. >>
> General::stop: Further output of Take::normal will be suppressed during this calculation. >>
> First::normal: Nonatomic expression expected at position 1 in First[Multpad]. >>
> First::argx: First called with 0 arguments; 1 argument is expected. >>
> First::argx: First called with 0 arguments; 1 argument is expected. >>
> First::normal: Nonatomic expression expected at position 1 in First[Multpad]. >>
> Take::argm: Take called with 0 arguments; 1 or more arguments are expected. >>
> Take::argm: Take called with 0 arguments; 1 or more arguments are expected. >>
> First::normal: Nonatomic expression expected at position 1 in First[Multpad]. >>
> General::stop: Further output of First::normal will be suppressed during this calculation. >>
> First::argx: First called with 0 arguments; 1 argument is expected. >>
> General::stop: Further output of First::argx will be suppressed during this calculation. >>
> Take::argm: Take called with 0 arguments; 1 or more arguments are expected. >>
> General::stop: Further output of Take::argm will be suppressed during this calculation. >>
> Function::slotn: Slot number 1 in {PRIVATE`CouplingObject[#1]}& cannot be filled from ({PRIVATE`CouplingObject[#1]}&)[]. >>
> Function::slotn: Slot number 1 in {PRIVATE`CouplingObject[#1]}& cannot be filled from ({PRIVATE`CouplingObject[#1]}&)[]. >>
> Function::slotn: Slot number 1 in {PRIVATE`CouplingObject[#1]}& cannot be filled from ({PRIVATE`CouplingObject[#1]}&)[]. >>
> General::stop: Further output of Function::slotn will be suppressed during this calculation. >>
> Transpose::nmtx: The first two levels of the one-dimensional list {{First[],First[1]},<<22>>[<<1>>,<<1>>],{{PRIVATE`CouplingObject[#1]},{<<22>>[False]}}} cannot be transposed. >>
> Transpose::nmtx: The first two levels of the one-dimensional list {{First[],First[1]},<<22>>[<<1>>,<<1>>],{{PRIVATE`CouplingObject[#1]},{<<22>>[False]}}} cannot be transposed. >>
> Transpose::nmtx: The first two levels of the one-dimensional list {{First[],First[1]},<<22>>[<<1>>,<<1>>],{{PRIVATE`CouplingObject[#1]},{<<22>>[False]}}} cannot be transposed. >>
> General::stop: Further output of Transpose::nmtx will be suppressed during this calculation. >>
> Join::heads: Heads List and PRIVATE`PrependToLines at positions 1 and 2 are expected to be the same. >>
> Join::heads: Heads List and PRIVATE`PrependToLines at positions 1 and 2 are expected to be the same. >>
> Join::heads: Heads List and PRIVATE`PrependToLines at positions 1 and 2 are expected to be the same. >>
> General::stop: Further output of Join::heads will be suppressed during this calculation. >>
> Transpose::list: List expected at position 2 in Transpose[{{\!\(\*OverscriptBox[\"b\", \"\\\"\<-\>\\\"\"]\),1},{b,2},{A,3}},Join[<<1>>]]. >>
> Transpose::list: List expected at position 2 in Transpose[{{\!\(\*OverscriptBox[\"c\", \"\\\"\<-\>\\\"\"]\),1},{c,2},{A,3}},Join[<<1>>]]. >>
> Transpose::list: List expected at position 2 in Transpose[{{\!\(\*OverscriptBox[\"d\", \"\\\"\<-\>\\\"\"]\),1},{d,2},{A,3}},Join[<<1>>]]. >>
> General::stop: Further output of Transpose::list will be suppressed during this calculation. >>
> - Optimizing: 139/139 .
> Transpose::argt: Transpose called with 0 arguments; 1 or 2 arguments are expected. >>
> MapAt::partw: Part {2} of #2 does not exist. >>
> Transpose::argt: Transpose called with 0 arguments; 1 or 2 arguments are expected. >>
> Transpose::argt: Transpose called with 0 arguments; 1 or 2 arguments are expected. >>
> General::stop: Further output of Transpose::argt will be suppressed during this calculation. >>
> - Writing files.
> StringJoin::string: String expected at position 2 in L.<>MapAt[PRIVATE`OptimizeIndexName,#2,2].
> StringJoin::string: String expected at position 2 in C.<>#3.
> StringJoin::string: String expected at position 1 in StringJoin[PYDicEntry[(0,0),C.<>#3]].
> General::stop: Further output of StringJoin::string will be suppressed during this calculation. >>
> Done!
>
> Thus nothing to say, I had to implement the couplings/vertices/parameter
> python files by hand, boring but "doable" I am already calculating.
>
> cheers,
>
> 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 : 		#5

Hi Olivier:

just to finish this thread, the error on model generation arises due to compatibility issues of FeynRules with my Mathematica. The words of FeynRules author were: "FeynRules is not compliant with Mathematica versions earlier than 7".

thanks for your concern,

cheers,

arian

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

Thanks for putting the information here.

Cheers,

Olivier
On Oct 2, 2013, at 8:51 AM, Arian Abrahantes <email address hidden> wrote:

> Question #236606 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/236606
>
> Arian Abrahantes posted a new comment:
> Hi Olivier:
>
> just to finish this thread, the error on model generation arises due to
> compatibility issues of FeynRules with my Mathematica. The words of
> FeynRules author were: "FeynRules is not compliant with Mathematica
> versions earlier than 7".
>
> thanks for your concern,
>
> cheers,
>
> arian
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.