CalcHep/CompHep
Inhaltsverzeichnis
Generate model files for CalcHep and CompHep
To generate model files for CalcHep and CompHep ,
MakeCHep[options]
is used. The following options exist.

FeynmanGauge
: defines, if Feynman gauge should be supported beside Landau gauge. This is done by default. 
CPViolation
: defines, if parameters should be handled as complex. By default, all parameters are treated as real because CalcHepis not really optimized for the usage of complex parameters and this option should be used carefully. 
ModelNr
: numbers the model files. SARAHstarts by default with1
. 
CompHep
: can be used to write model files in CompHepinstead of CalcHepformat. 
NoSplittingWith
: SARAHdoes not decompose fourscalar interactions in pairs of two scalar interactions with auxiliary fields if particular fields are involved. Such a decomposition is usually done because of the implicit colour structure in CalcHepwhich doesn’t allow fourpoint interactions of coloured states. To keep the model files shorter, SARAHmakes the same decomposition also for noncoloured states. 
NoSplittingOnly
: One can define particles, for which SARAHdoes not decompose fourscalar interactions in pairs of two scalar interactions with auxiliary fields if only the given fields are involved the interaction. 
UseRunningCoupling
: defines, if [math]\alpha_S[/math] should run in the model files. 
SLHAinput
: defines, if parameter values should be read from a spectrum file. 
CalculateMasses
: defines, if treelevel masses should be calculated internally by CalcHep. 
RunSPhenoViaCalcHep
: writes C code to run SPhenofrom the graphical interface of CalcHepto calculate the spectrum on the fly. 
IncludeEffectiveHiggsVertices
: defines, if effective Higgs vertices [math]h\gamma\gamma[/math] and [math]hgg[/math] should be included. 
DMcandidate1
: sets the first DM candidate. 
DMcandidate2
: sets optionally a second DM candidate.
The CalcHep output can also be used with MicrOmegas for the calculation of dark matter properties.
Further information about the output
Model Files
The CalcHep / CompHep output of SARAH generates the following four files

prtclX.mdl
: Contains all particles 
lgrngX.mdl
: Contains the interactions 
varsX.mdl
: Contains the numerical values of the variables 
funcX.mdl
: Contains dependences between the parameters
X
is a number, which can be chosen by the option ModelNr
.
Particles
First, there are stringent constraints on the naming of particles in CalcHep : only names up to four letters are allowed and also indices aren’t supported. Therefore, it is not possible to use the SARAH internal definitions of particles. Thus, the names used for the model files are based on the defined OutputName
of each particle in the following way
 The basis of each name is the entry in
OutputName
in the particle file, see sec. [particleFile]  If the considered particle is not selfconjugated, for the anti particle the first letter is changed from upper to lower case or vice versa.
 If there are more generations for one particle, the number of the generation is appended at the end of the name
 If the defined Rparity is 1, a
~
is added to the beginning of the name to assign SUSY particles. In this way, it is possible to use the model files in MicrOmegas without the need of an additional list of all SUSY particles
The steps above are the standard procedure for all vector bosons, fermions and most scalars. Ghosts, Goldstone bosons and auxiliary fields handled in a different way. There are three different kind of ghosts. These are not written in the particle file, but appear in the Lagrangian file:
FaddeevPopov Ghost: these are the well known Ghost derived from the gauge transformations of the gauge fixing term. The name in the model file is
"Name of Vector Boson".C
Goldstone Ghosts: these are just the Goldstone bosons ’eaten up’ by the gauge particles. Their name is
"Name of Vector Boson".f
Tensor Ghosts: Is needed to express the four gluon interaction. The name is
"Name of Gluon".t
SARAH derives the name of Goldstone and FaddeevPopov ghost automatically from the underlying vector boson, but the tensor ghost and its one interaction with two gluons is hardcoded.
The last kind of fields known by CalcHep / CompHep are auxiliary fields. Their purpose is explained in the next section, but their names are as follows
~OX
Here, X
is an integer. The antiparticle, if it is not the same, is counted as X+1.
Auxiliary fields in CalcHep / CompHep
We mentioned in the last section that CalcHep and CompHep needs special auxiliary fields. The reason is that the color structure is implicit. Hence, interactions of four colored particles or two colored and two gluons suffer from an ambiguity. Therefore, these interactions are split in two three particle interactions by inserting auxiliary fields.
SARAH does a similar splitting for all interactions between four scalars by inserting auxiliary fields when calculating the F and DTerms. Also the interactions between two squarks and two gluons are split in two three particle interactions. The splitting can be suppressed for specific vertices by using NoSplittingWith
or NoSplittingOnly
.
Vertex functions
All interactions are parametrized by a variable in the Lagrange file. The values of these variables are defined by using the results of SARAH for the corresponding vertices. The following renaming had to be done:
Tensor indices are just added to the name, therefore all sums in the vertices had do be evaluated:
sum[i1,1,3,MD[1,i1]] > MD11 + MD12 + MD13
Some values, which are known to be zero like in the flavor conserving case, are set to zero at this point.
Variables names, which are longer then six letters, are truncated.
All parameters are assumed to be real, i.e. complex conjugation is removed (see sec. [CPCH]).
The generators and structure constants of the strong interaction are removed because they are defined implicitly.
possible combinations of generation indices. This can lead for some models to a very long time for writing the model file, e.g. in the [math]\mu \nu SSM[/math] with 8 charged Higgs: All [math]8^3[/math] combinations of the self interactions must be written.
CP Violation
CalcHep / CompHep can’t handle complex values in the function or vars file, but only in the Lagrange file. Therefore, all variables are by default assumed to be real, when SARAH writes the model file with default options. This can be changed by settingCPViolation
toTrue
. In that case, SARAH splits all parameters, which are not explicitly defined as real, in real and imaginary part:
X > RX + i*IX
The real and imaginary part for every interaction is calculated using that splitting, and both parts are written separately in the Lagrange file:
v0001 > Rv0001 + i*Iv0001
SARAH writes in this file the output name of every needed variable. Since CalcHep / CompHep does only support variable names with a length of maximal 6 letters, SARAH cuts the name of all variables, which are longer then that. If a numerical value for the variable is available, e.g. if it is defined in the parameter file or it was read in from LesHouches file, it will also be added in the vars
file, otherwise NaN
appears.func1.mdl
.
SLHA input
CalcHep supports the possibility to read LesHouches input files . SARAH can write the corresponding definitions in the functions file of CalcHep . In this context, it is assumed that a LesHouches file called SPheno.spc.[MODEL]
is located in the same directory. However, this can easily be adjusted manually.
What can be a problem...
We have made the following experiences by testing model files with CalcHep / CompHep :
 A PDG number of
0
is not allowed for other particles than auxiliary particles.  In the vars file is no discrimination between small and capital letters. This must be taken into account by naming the mixing matrices and couplings in SARAH .
 Higher dimensional operators are not supported
 The color structure is implicit and indices are not supported in CalcHep / CompHep . Therefore, it is difficult to implement models with other unbroken nonAbelian gauge groups than the color group.
 Writing the output for models with particles appearing in a large number of generations and non reducible mixing matrices like in the flavor conserving MSSM, last very long, because all possible combinations of indices have to be written separately.
See also
 MicrOmegas
 CalcHep/CompHep
 FeynArts
 LaTeX
 LHCP
 SPheno
 UFO
 Vevacious
 WHIZARD
 Generating the different outputs