Hard Coded SM Groups?
Hard Coded SM Groups?
At present, the Standard Model gauge coupling names seem to be hard coded, so if I wish to rename Left-Coupling to Weak Coupling, I get errors that the model has no left coupling defined.
It would be good if I could use my own name for these variables and then, perhaps as an extra parameters in parameters.m to indicate which SM group a particular gauge relates to.
PS: Feel free to move this post to a more appropriate forum as you see fit.
It would be good if I could use my own name for these variables and then, perhaps as an extra parameters in parameters.m to indicate which SM group a particular gauge relates to.
PS: Feel free to move this post to a more appropriate forum as you see fit.
Joshua Ellis jpellis.me
Re: Hard Coded SM Groups?
Hi,
the procedure is that you are free to choose any symbol for a coupling (e.g. g2, gW, g,.. for the SU(2)_L coupling) and then tell SARAH via the Description statement if this parameter has a particular meaning. At the moment the following names for parameters are understood by SARAH:
The parameters are mainly used in the SPheno output to get the matching between current model and SM and to support an output in the SCKM basis.
What is not clear to me, why do you want to define your own name? It seems to me that it doesn't play any role how the parameters are called as long as it is easy to understand (and unique). This name also doesn't show up in any output, if I remember correctly.
Cheers,
Florian
the procedure is that you are free to choose any symbol for a coupling (e.g. g2, gW, g,.. for the SU(2)_L coupling) and then tell SARAH via the Description statement if this parameter has a particular meaning. At the moment the following names for parameters are understood by SARAH:
Code: Select all
"Neutrino-Mixing-Matrix",
"Up-Yukawa-Coupling",
"Down-Yukawa-Coupling",
"Lepton-Yukawa-Coupling",
"Offdiagonal Up-Yukawa Coupling",
"Offdiagonal Down-Yukawa Coupling",
"Offdiagonal Electron-Yukawa Coupling",
"Hypercharge-Coupling",
"Left-Coupling",
"Strong-Coupling",
"electric charge",
"Up-Squark-Mixing-Matrix",
"Neutralino Mixing-Matrix",
"Chargino-plus Mixing-Matrix",
"Chargino-minus Mixing-Matrix",
"Slepton-Mixing-Matrix",
"Sneutrino Mixing-Matrix",
"Down-Squark-Mixing-Matrix",
"Left-Lepton-Mixing-Matrix",
"Right-Lepton-Mixing-Matrix",
"Left-Down-Mixing-Matrix",
"Right-Down-Mixing-Matrix",
"Left-Up-Mixing-Matrix",
"Right-Up-Mixing-Matrix",
"CKM Matrix",
"Weinberg-Angle",
"Down-VEV",
"Up-VEV",
"EW-VEV",
"Scalar mixing angle",
"Pseudo Scalar mixing angle",
"Scalar-Mixing-Matrix",
"Pseudo-Scalar-Mixing-Matrix",
"Softbreaking right Down-Squark Mass",
"Softbreaking right Up-Squark Mass",
"Softbreaking left Slepton Mass",
"Softbreaking right Slepton Mass",
"Softbreaking left Squark Mass",
"Trilinear-Up-Coupling",
"Trilinear-Down-Coupling",
"Trilinear-Lepton-Coupling",
What is not clear to me, why do you want to define your own name? It seems to me that it doesn't play any role how the parameters are called as long as it is easy to understand (and unique). This name also doesn't show up in any output, if I remember correctly.
Cheers,
Florian
Re: Hard Coded SM Groups?
It seems like you have listed most of the descriptions located in the global parameters.m though there are a few which I don't recognise, such as off-diagonal fermion mixing matrices.
My understanding is that when I describe a new parameter, SARAH uses the Description -> "..." key to corss-reference that with that with the global parameters.m file; thereby preventing information from being always repeated.
If my interpretation is correct, then I should be also be able to specify an arbitrary Description -> "..." and thus not rely on the global parameters.m file as long as I have all the appropriate properties defined.
For example, I should be able to have in my model's parameters.m
and it should work fine.
The reason I am doing that is I want to be absolutely clear about what I have defined and what I have not, and how they are defined. For example, I want to know whether I am defining things in relation to the coupling constants, or the boson masses. In addition, I can be a little pedantic about having consistent naming schemes. For example, you always have "X-Boson" and "X-Boson Ghost" with the one exception of the Z' where its ghost is "Z'-Ghost" despite the boson being called "Z'-Boson". You also have some inconsistencies with dashes vs spaces, and capitalisation...
My understanding is that when I describe a new parameter, SARAH uses the Description -> "..." key to corss-reference that with that with the global parameters.m file; thereby preventing information from being always repeated.
If my interpretation is correct, then I should be also be able to specify an arbitrary Description -> "..." and thus not rely on the global parameters.m file as long as I have all the appropriate properties defined.
For example, I should be able to have in my model's parameters.m
Code: Select all
{{
Description -> "Weak Coupling",
LaTeX -> "g_2",
DependenceOptional -> e/Sin[ThetaW],
DependenceNum -> e/Sin[ThetaW],
LesHouches -> {gauge, 2},
OutputName-> g2
}}
The reason I am doing that is I want to be absolutely clear about what I have defined and what I have not, and how they are defined. For example, I want to know whether I am defining things in relation to the coupling constants, or the boson masses. In addition, I can be a little pedantic about having consistent naming schemes. For example, you always have "X-Boson" and "X-Boson Ghost" with the one exception of the Z' where its ghost is "Z'-Ghost" despite the boson being called "Z'-Boson". You also have some inconsistencies with dashes vs spaces, and capitalisation...
Joshua Ellis jpellis.me
Re: Hard Coded SM Groups?
Some parameters are not used for anything particular in the outputs. In these cases, the description is used to have globally the LaTeX names, Les Houches block, etc.It seems like you have listed most of the descriptions located in the global parameters.m though there are a few which I don't recognise, such as off-diagonal fermion mixing matrices.
Exactly. However, as soon as you define a property locally of a parameter, the global definition is overwritten. Therefore, you can still use the standard names, and just overwrite anything what you want to change. If you want to get rid of some properties, use 'None', e.g.My understanding is that when I describe a new parameter, SARAH uses the Description -> "..." key to corss-reference that with that with the global parameters.m file; thereby preventing information from being always repeated.
Code: Select all
...
DependencenNum -> None,
...
You can always look at ParameterDefinitions after the model is loaded in SARAH. SARAH lists then all entries which it is currently using for each parameter.I want to know whether I am defining things in relation to the coupling constants, or the boson masses.
I can't say that I'm very pedantic about these things as you have recognised. I try to improve that in the future.In addition, I can be a little pedantic about having consistent naming schemes.

Re: Hard Coded SM Groups?
In the previous post:
and digging a little further, I have found the following description keys to be hardcoded in the SPheno part of SARAH:
Is this an exhaustive list of parameter descriptions which are hardcoded?
However, this is in contradiction to your source code as you have hard-coded these names. For example, taking "Hypercharge-Coupling", the following files and lines match (in SARAH v4.8.5):FStaub wrote:Exactly. However, as soon as you define a property locally of a parameter, the global definition is overwritten. Therefore, you can still use the standard names, and just overwrite anything what you want to change. If you want to get rid of some properties, use 'None', e.g.JPEllis wrote: My understanding is that when I describe a new parameter, SARAH uses the Description -> "..." key to corss-reference that with that with the global parameters.m file; thereby preventing information from being always repeated.
Code: Select all
File | Line
----------------------------------+------
Package/SPheno/SPhenoRGEsSM.m | 237
Package/SPheno/SPhenoRGEsSM.m | 293
Package/SPheno/SPhenoLoopMasses.m | 443
Package/SPheno/SPheno.m | 678
Package/SPheno/SPheno.m | 680
Package/SPheno/SPheno.m | 1138
Package/SPheno/SPheno.m | 1142
Package/SPheno/SPheno.m | 1161
Package/SPheno/SPheno.m | 1164
Package/SPheno/SPheno.m | 1170
Package/SPheno/SPheno.m | 1173
Package/SPheno/SPhenoLowEnergy.m | 1064
Package/SPheno/SPhenoLowEnergy.m | 1079
Code: Select all
Up-Yukawa-Coupling
Down-Yukawa-Coupling
Lepton-Yukawa-Coupling
Hypercharge-Coupling
Left-Coupling
Strong-Coupling
Left-Lepton-Mixing-Matrix
Right-Lepton-Mixing-Matrix
Left-Down-Mixing-Matrix
Right-Down-Mixing-Matrix
Left-Up-Mixing-Matrix
Right-Up-Mixing-Matrix
Down-VEV
Up-VEV
Scalar-Mixing-Matrix
Joshua Ellis jpellis.me
Re: Hard Coded SM Groups?
I don't see any contradiction. As I just said, you can define all properties for the standard names locally. So, I don't see any need to allow for the possibility to change the names. In addition, you'll need then to define another keyword to tell SARAH if a given parameter is associated with some SM parameter for instancen. And this keyword needs to be hard-coded again, of course. So, what would you gain?JPEllis wrote:In the previous post:
However, this is in contradiction to your source code as you have hard-coded these names.
I already gave a list in my first reply. You can also check init.m if you want.Is this an exhaustive list of parameter descriptions which are hardcoded?