Changes between Version 15 and Version 16 of WhizardInterface

Timestamp:

Mar 23, 2010, 4:27:04 PM (15 years ago)

Author:

Christian Speckner

Comment:

--

WhizardInterface

@@ -16 +16 @@
 
  * {{{WOVertexList}}}: If {{{=!= Null}}}, this is interpreted as a list of Feynman rules and overrides any Lagrangian (or -list) specified (in this case, {{{Null}}} is accepted as first argument). Default: Null
- * {{{WOModelName}}}: The name by which the model will be identified in WO. Note that all models for W1.9x have to start with "fr" (e.g. {{{WOModelName->"fr_sm"}}}) if they are to be picked up by WO1.9x without user intervention (no such restriction exists for W2). Beware that the interface my modify this name if it doesn't fit into the WO naming schemes --- double check the generated messages to be sure. Default: derived from the FR model name
- * {{{WOMaxNcf}}}: Upper limit on the number of color flows which the generated code will be able to handle (essentially n_8 - n_3 / 2, where n_8 is the maximum number of external octets and n_3 that of external triplets). Irrelevant for W2; also, the technically experienced user can change this after generation in {{{f90_modellname_Col.ml}}}. Default: 4
+ * {{{WOModelName}}}: The name by which the model will be identified in WO. Note that all models for W1.9x have to start with "fr" (e.g. {{{WOModelName->"fr_sm"}}}) if they are to be picked up by WO1.9x without user intervention (no such restriction exists for W2). Beware that the interface may modify this name if it doesn't fit into the WO naming schemes --- double check the generated messages to be sure. Default: derived from the FR model name
+ * {{{WOMaxNcf}}}: Upper limit on the number of color flows which the generated code will be able to handle (essentially n_8 - n_3 / 2, where n_8 is the maximum number of external octets and n_3 that of external triplets). Irrelevant for W2; also, the technically inclined user can change this after running the interface in {{{f90_modellname_Col.ml}}}. Default: 4
  * {{{WOGauge}}}: The following gauges are available:
   * {{{WOUnitarity}}}: Unitarity gauge (default)
   * {{{WOFeynman}}}: Feynman gauge
   * {{{WORxi}}}: Rxi gauges. In this case, you __must__ define a parameter taking the role of \xi and pass it to the interface via {{{WOGaugeParameter}}} (see below).
- * {{{WOGaugeParameters}}}: The parameter which takes the role of \xi in the Rxi gauges, can be either a string or a symbol. Default: "Rxi"
+ * {{{WOGaugeParameter}}}: The parameter which takes the role of \xi in the Rxi gauges, can be either a string or a symbol. Default: "Rxi"
  * {{{WOWhizardVersion}}}: Select the WO version for which you want to generate code. Possible choices:
   * {{{"1.92"}}}: WO 1.92
@@ -50 +50 @@
 
 == Usage: WO 2.0 ==
-WO 2.0 and above natively support the addition of new models without recompiling WHIZARD. More specifically, WHIZARD looks for any model specific files first in the uses local installation tree {{{${HOME}/.whizard}}} and the in the global installation tree {{{${PREFIX}}}}. Therefore, in order to use an external model with WO2, the O'Mega binaries and FORTRAN libraries must be compiled and installed in the proper directory together with the WHIZARD model definition. To the end, the WO interface creates a standard autotoolized (don't worry if you don't know what this means) {{{./configure; make install}}} type build system in the output directory. To use it, you must perform three steps (in the output directory):
+WO 2.0 and above natively support the addition of new models without recompiling WHIZARD. More specifically, WHIZARD looks for any model specific files first in the uses local installation tree {{{${HOME}/.whizard}}} and the in the global installation tree {{{${PREFIX}}}}. Therefore, in order to use an external model with WO2, the O'Mega binaries and FORTRAN libraries must be compiled and installed in the proper directory together with the WHIZARD model definition. To the end, the WO interface creates a standard autotoolized (don't worry if you don't know what this means) {{{./configure; make install}}} type build system in the output directory. The build system supports multiple models in one output directory. To use it, you must perform three steps (in the output directory):
 
 1) Configuration
@@ -73 +73 @@
 
  * The interface will refuse to write output to a directory which already contains model files generated for a different WO version.
- * The list of supported operators is essentially limited to renormalizable operators of dimension <= 4 together with some renormalizable higher dimension ones (e.g. three point graviton-x-x couplings in ADD). This will be expanded in the future.
+ * The list of supported operators is essentially limited to operators of dimension <= 4 together with some higher dimension ones (e.g. three point graviton-x-x couplings in ADD like models). This list will be expanded in the future.
  * If vertices are skipped due to unidentified Lorentz structures, the option {{{WOFast -> False}}} can be used to enable more expensive checks for known operators.
  * Color structures are implicit in O'Mega and derived from the SU(3) representations of the particles at the vertex, limiting the currently available color structures. However, the interface will complain if an unsupported structure is encountered.
- * For ADD-like graviton-x-x couplings, the mass of the particles couplings to the graviton '''must''' be declared as symbolic values (which, however, can be external parameters) if the vertex is to recognized.
- * Make sure that the gauge used in the definition of the model matches that used by the interface (c.f. {{{WOGauge}}}).
+ * For ADD-like graviton-x-x couplings, the mass of the particles couplings to the graviton __must__ be declared as symbolic values (which, however, can be external parameters) if the vertex is to recognized.
+ * Make sure that the gauge used in the definition of the model matches that used by the interface (c.f. {{{WOGauge}}}). NB: If you allow the interface to automatically assign the goldstone boson masses via {{{WOAutoGauge}}} (the default), then any Feynman gauge model can be used for the Rxi gauges as well, provided that you define a parameter for \xi (see WOGaugeParameter above).
  * Complex parameters are automatically split into real and imaginary parts (with {{{_r}} resp. {{{_i}}} appended to the parameter name).
 
@@ -84 +84 @@
  * In order to be picked up by WHIZARD automatically, the model name must start with {{{fr}}} (c.f. the above description of {{{WOModelName}}}).
  * If you want to simulate processes with many external colored particles (e.g. 5+ gluons), you must increase {{{WOMaxNcf}}} from its default (see above).
- * WO 1.9x does not support running \alpha_S.
+ * WO 1.9x does not support running \alpha_s.
 
 == Notes & caveats for the unwary : WO 2.0 ==
 
- * Complex internal parameters are currently limited to polynomials of complex parameters.
- * All parameters given in the {{{WORunParameters}}} list as well as all vertex factors depending on those are recalculated when \alpha_S is run. If you want to have \alpha_S running at some vertices and constant at others (e.g. gluino vertices), you can do so by defining an alias for \alpha_S as a derived parameter.
+ * Accepted complex internal parameters are currently limited to polynomials of complex parameters.
+ * All parameters given in the {{{WORunParameters}}} list as well as all vertex factors depending on those are recalculated when \alpha_s is run. If you want to have \alpha_s running at some vertices and constant at others (e.g. gluino vertices), you can do so by defining an alias for \alpha_s as a derived parameter.