CalcHep CompHep

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 with 1.
• CompHep: can be used to write model files in CompHepinstead of CalcHepformat.
• NoSplittingWith: SARAHdoes not decompose four-scalar 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 four-point interactions of coloured states. To keep the model files shorter, SARAHmakes the same decomposition also for non-coloured states.
• NoSplittingOnly: One can define particles, for which SARAHdoes not decompose four-scalar interactions in pairs of two scalar interactions with auxiliary fields if only the given fields are involved the interaction.
• UseRunningCoupling: defines, if α_S should run in the model files.
• SLHAinput: defines, if parameter values should be read from a spectrum file.
• CalculateMasses: defines, if tree-level 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 hγγ and hgg 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

1. prtclX.mdl: Contains all particles
2. lgrngX.mdl: Contains the interactions
3. varsX.mdl: Contains the numerical values of the variables
4. 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

1. The basis of each name is the entry in OutputName in the particle file, see sec. [particleFile]
2. If the considered particle is not self-conjugated, for the anti particle the first letter is changed from upper to lower case or vice versa.
3. If there are more generations for one particle, the number of the generation is appended at the end of the name
4. If the defined R-parity 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:

1. Faddeev-Popov 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

2. Goldstone Ghosts: these are just the Goldstone bosons ’eaten up’ by the gauge particles. Their name is "Name of Vector Boson".f

3. Tensor Ghosts: Is needed to express the four gluon interaction. The name is "Name of Gluon".t

SARAH derives the name of Goldstone and Faddeev-Popov ghost automatically from the underlying vector boson, but the tensor ghost and its one interaction with two gluons is hard-coded. 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 D-Terms. 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:

1. 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.

2. Variables names, which are longer then six letters, are truncated.

3. All parameters are assumed to be real, i.e. complex conjugation is removed (see sec. [CPCH]).

4. 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 μνSSM with 8 charged Higgs: All 8³ 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 setting CPViolation to True. 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 :

1. A PDG number of 0 is not allowed for other particles than auxiliary particles.
2. 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 .
3. Higher dimensional operators are not supported
4. The color structure is implicit and indices are not supported in CalcHep / CompHep . Therefore, it is difficult to implement models with other unbroken non-Abelian gauge groups than the color group.
5. 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