Vincent Lafage's Home Page
lafage@lapp.in2p3.fr

MUSE: a MUltiscale Spectrum Evaluator


Table of Contents
1. Background of Spectrum Evaluators
1.1 Position of the problem
1.2 Existing Spectrum Evaluators
2. MUSE
2.1 Getting the code
2.2 Installing
2.3 Running
2.4 Scanning
3. Some results
This document discusses the SUSY spectrum evaluator software that is available, and explain the specifics of MUSE.

There exists an assortment of evaluator packages, some considered to be the ultimate word. Their main advantage is to be integrated in famous events generator packages: IsaJet and Pythia, which are considered ``industry standard''. Nevertheless, comparing these two shows discrepancies of 3% in the squark sector.

In the Higgs sector, most evaluators are coupled to the popular routine(s) of Carena and Wagner (see also Wagner). The more recent routine FeynHiggs and its simplified version FeynHiggsFast have not yet found their way in a full spectrum evaluator.

1. Background of Spectrum Evaluators

1.1. Position of the problem

SUSY is a very attractive theory, yet it requires a lot of extra parameters to break it softly: enough not to see it, but not so much as to lose its advantages (like solving the hierarchy problem). One counts about 80 soft breaking terms, plus possibly 40 CP-violating phases in the MSSM (without mentionning MSSM extended to R-parity breaking).

That many free parameters isn't manageable when one consider a realistic physics simulation, from the Lagrangian to the detector efficiencies. One usually restricts the number of free parameters with GUT-like universality assumption: at some high-scale, where the gauge coupling unify, the soft-breaking term will also get common value. The most common set of universality assumptions is the minimal SUper-GRAvity (mSUGRA) model: one common value for gaugino masses, one for scalar masses, and one for trilinear coupling.

In order to extract the physical spectrum of this model, one has to ``run down'' the parameters from the Unification scale to the electroweak scale through the Renormalisation Group Equations (RGE). This is only a rough sketch: in fact, one must stop at all scales corresponding to each particle mass:

Pole masses


To lift the ambiguity on the scale at which one evaluate the running masses, one has to go to the definition of pole mass. The pole mass is a proper observable: renormalisation group invariant, gauge invariant, infrared safe.

Computing it involves two things:

  • evaluating the running mass at the scale of the pole mass (leading logarithm)
  • evaluating the self-energy finite correction.
Even forgetting the finite correction, this provide an unambiguous definition. This point require in principle a multiscale spectrum evaluator (with one scale for each mass to evaluate). In the particular case of mSUGRA, the masses most affected by the running are definitely the ones of squark and sgluino.

We can face two problems:

  • extract the running mass from the (experimental) pole mass (for computing the Yukawa coupling of fermions), which is straightforward.
  • compute the pole mass from the running one, which involve solving a non-linear equation.
In fact, one must provide one boundary condition for each equation of the RGE system of first order Ordinary Differential Equation. But all these boundary conditions are not defined at the same scale:
  • the gauge coupling must unify at the GUT scale, and fit their experimental value at M_Z (in fact, this is overconstrained if one consider the 3 gauge couplings. As a consequence, one must choose between unification of strong coupling (trinification) or fitting its experimental value)
  • the Yukawa couplings of the fermion are best defined at the pole mass of the related fermion
  • the soft breaking terms unify at the GUT scale, with a value provided as input by the model builder
  • the mu and b parameter are defined by the radiative ElectroWeak Symmetry Breaking (EWSB) condition at the EWSB scale as function of \tan\beta, M_Z, M^2_H_1 and M^2_H_2
Some of this conditions are trivial to implement (Soft Breaking Terms), but others are not even always defined (EWSB). We need to consider these conditions as a set of non-linear equations. The system of ODE is thus coupled not only through the beta functions (derivative of the parameter) but also by its boundary conditions.

When expressed at one-loop level, this conditions depends in turn on the spectrum to be evaluated: we end up with a feed-back problem. The usual solution to this problem is iterative.

1.2. Existing Spectrum Evaluators

    Spythia is using semi-analytical formula to solve the RGE with one loop beta functions. Unification is realised with semi-analytical formula. While quick and straightfoward, this cannot be extended to deal with higher loop effect nor thresholds.

    IsaSUSY is solving numerically the set of beta functions (2-loop for the gauge, and 1-loop for the other), including thresholds (sharp theta function), using 4th order Runge-Kutta algorithm with fixed step. Unification is realised numerically with an accuracy of 5 permille.

    SuSpect. The french SUSY-GDR (Groupement De Recherche) tools group decided to build their own tool to solve the discrepancies between Spythia and IsaSUSY. This code is solving numerically the set of beta functions (2-loop for the gauge, and 1-loop for the other), including thresholds (smoothed theta function, in spite of the minimal substraction scheme), using 4th order Runge-Kutta algorithm with step doubling for controlling accuracy. Unification is approximately realised with semi-analytical formula (1-loop, no threshold).

    MUSE.(tools group).This code is solving numerically the set of beta functions (up to 3-loop for the gauge, 2-loop for the Yukawa and some of the soft breaking terms), including thresholds (sharp theta function), using Predictor-Corrector algorithm with very high accuracy (10^-13 relative uncertainty). Unification is exactly realised through simultaneous numerical solution of the set of constraints. Accuracy of the solution is explicitely provided in the end of the run.

    MUSE is designed for speed and accuracy, to be extensible to new radiative corrections, to be used as automatically as possible for scans, and as flexibly as possible when trying to compare to other evaluators. Different level of complexity can be selected through switches.

2. MUSE

2.1. Getting the code

MUSE is written in Fortran, and comply to the 77 standard with the following exceptions:
  • implicit none
  • include statement
  • DO... ENDDO structure
  • more than 6 characters variable name
  • use of lower-case and underscore, as well as backslash in the strings
It has been built successfully on the the following compilers: g77, f2c+gcc, HP Fortran, Hitachi Fortran 90, Digital Fortran.
*ATTENTION* in some cases, you must indicate the use of `\' (backslash) in strings to your compiler, as well as (reporting NaN instead of sending an interrupt).
f2c compiler leads to a run-time failure when optimisation is selected.

2.2. Installing

The installation proceeds as follows:
  1. Expand the archive
  2. gzip -dc muse.tar.gz | tar xvf -
    Alternatively
    gtar zxvf muse.tar.gz
  3. Edit the beginning of `Makefile' to describe your compiler's command line
  4. F77 = your compiler
    FFLAGS = compilation options, if any
    (some configurations are already provided)
  5. Type `make'

  6. (please report any failure at lafage@minami.kek.jp, by completing and sending the file BUGREPORT)
  7. You can try a set of example points by sending the `BATCH' file
  8. source BATCH
    The results will be stored in the directory zresult.
    The reference results are in the directory zresult0 for comparison. Only the execution time and last digits should change from a computer to another !!!
    Nevertheless, some architectures (Intel x86-based for instance) will compute with higher accuracy (internal format REAL*10). As a consequence some points can converge on these computers, but not on other workstations (out.gdr8, out.gdr14).
  9. The executable is called `muse'. You can edit the parameters of the Standard Model in DATA/sm.dat and provide you Grand Unification scale hypothesis in the format of DATA/dpf1.dat for instance. You have to provide the names of these two files in `filename.dat'.
Much flexibility in the choice of the hypothesis is provided, through the use of switches in the file `nume.dat'.
The methods allowed in this version are 4 & 5 only, because the Numerical Recipes method cannot be released.
For the same reason, only MinPack routines can be used.

2.3. Running

    Before running MUSE, one needs to set the following files `filename.dat'

    `nume.dat'

  • number of parameters
  • number of equations
  • ODE relative size of initial step
  • ODE integration required accuracy
  • ODE smallest step allowed as fraction of initial step
  • NLE TOLF=
  • NLE TOLMIN=
  • NLE TOLX=
  • NLE STPMX=
  • ODE method : 1=CK, 2=SD, 3=BS, 4=PC, 5=PCS
  • polynomial extrapolation in BS method
  • uses MinPack routines ?
  • loop(s) for gauge couplings RGE
  • loop(s) for yukawa couplings RGE
  • loop(s) for soft breaking RGE
  • uses thresholds in RGE
  • computed threshold ?
  • mSUGRA ?
  • unification at Lambda
  • gauge trinification
  • convert alpha strong from MSbar to DRbar
  • EW breaking enforcement
  • one-loop potential minimisation
  • Higgs correction by Carena et al.
  • All corrections to top mass in Carena et al.
  • Scale Lambda
  • SUSY common threshold
  • scaling for conditioning
  • loud report
  • scan mode (store to BANK)
  • print flag for score
  • print flag for LSODE
  • print format

2.4. Scanning

3. Some results