FormCalc Troubleshooting

Every serious bug report on FormCalc is appreciated and helps to make the program better. Please understand, however, that this free customer support takes a lot of time that I would love to spend on other projects. I will not teach Mathematica, Unix, or compiler basics, nor will I debug your program unless the problem very obviously points to a bug in FormCalc.

Keep in mind also that perturbative calculations are a tricky subject. FeynArts and FormCalc will take over many of the technical difficulties in such calculations, however they won't do the thinking for you. If you don't understand quantum field theory, you are in no good position to use FeynArts and FormCalc.

Following is a list of common problems and their solutions, and of things to check when encountering a problem. Please report only problems not listed here. Helpful links: How To Ask Questions The Smart Way, How To Report Bugs Effectively.

Problems in the setup

Mandrake users: FormCalc's compile script needs to invoke mcc, the MathLink C Compiler. Unfortunately, the name mcc stands for Mandrake Control Center on Mandrake. This means you have to invoke compile as e.g. "MCC=/usr/local/bin/mcc ./compile" (this is bash syntax).
Mathematica versions before 4.1 shipped with a MathLink library (libML.a) which is not compatible with recent glibc versions. If this is the case, the MathLink program will give a segmentation fault when invoked. You can test that you have a correct version by invoking the ReadForm executable from the command line: ./Linux/ReadForm. This should respond with "Create Link:". If you get a segfault instead, install the latest version of the MathLink Software Developer's Kit.
On Intel Macs you get the compilation error
```
Compiling for system type MacOSX-x86
     CC=tools/fcmcc mcc -O3 -fomit-frame-pointer -ffast-math  -o MacOSX-x86/ReadForm FormCalc/ReadForm.tm
     /bin/sh: line 1: mcc: command not found
     make[1]: *** [MacOSX-x86/ReadForm] Error 127
```
This is due to the fact that so far no MathLink SDK is available for that platform. For the moment, please download the PowerPC executable ReadForm.gz which should run on Intel Macs with the Rosetta emulator. Unzip that file and move it to the directory FormCalc/MacOSX-x86/. Then run the compile script again.

Problems in the FORM/Mathematica part

Make sure you're using the latest FORM version (at least 3.1).
If your FORM code stops with an error, edit the temporary FORM file which was created (e.g. /tmp/m1.frm) and remove the first line (#-). This will make FORM list the program code during execution. Run the file manually, i.e. do "form /tmp/m1". It should now be straightforward to localize the error.
If it is still unclear where the problem originates from after the last step, add "#preout on" to the beginning of /tmp/m1.frm and re-run FORM. The latter will now dump the code after preprocessor substitutions.
The default for CalcFeynAmp is to express external fermions through Weyl chains. If you want to use HelicityME and/or PolarizationSum later, you need Dirac chains, however. Use the option FermionChains -> Chiral in CalcFeynAmp.
You get an error message like the following:
```
ReadForm::formerror: MNeu has been declared as a symbol already
     Illegal use of function arguments
     Internal error in code generator. Unknown object: -25
```
This happens when there is a Classes-level field (in this case a neutralino, F[11]) on an external leg. This is a conceptual, not a technical problem. Firstly, FeynArts correctly puts MNeu because a Classes-level external particle is requested. Secondly, even if FeynArts generated a dummy index for this, such that the mass became MNeu[index], the amplitude as such would have no obvious physical meaning. Is it supposed to be a sum over all neutralinos? (The coherent or the incoherent sum?) Or should it be the cross-section for any neutralino? (But which one?) In other words, you need to choose a particular neutralino, i.e. put F[11, {2}] or F[11, {n}] as the external particle. Note that in the latter case you also have to declare the index n in your Fortran code.
When calculating QCD processes, you get a warning message like the following:
```
RenConst::nodef: Warning: {dZg1, dZGG1} might be renormalization
     constants, but have no definition.
```
This is in the first place a physics (renormalization) question and not one of FormCalc or FeynArts programming: dZGG1 is not defined because the physics is not as straightforward as for the photon. After all, the gluon is a confined particle. It is fairly trivial to add something analogous to the photon, e.g. RenConst[dZGG1] := FieldRC[V[5]], but what would that mean? What exactly is an on-shell gluon? Many QCD calculations are done in the MSbar scheme, where RenConst[dZGG1] := UVDivergentPart[FieldRC[V[5]]]. For simplicity, you can even put RenConst[dZGG1] := 0 if at the same time you choose delta = 0, mudim = 1 in LoopTools.

Problems in the Fortran part

You get a compilation error like the following:
```
     fortcom: Error: ./xsection.F, line 150: This name does not have a type,
     and must have an explicit type.   [PROCESS_H_NOT_UPDATED_YET]
     newthreshold = max(DBLE(process_h_not_updated_yet + ME), DBLE(MT + MT))
     ------------------------^
     compilation aborted for run.F (code 1)
```
Before you can compile the generated code, you have to edit the files process.h and run.F and enter the process definitions, model choice, etc. The symbol process_h_not_updated_yet intentionally produces a compilation error to remind the user of this.
If the cross-section is very large, of order 10¹²³: You probably forgot to compute the colour matrix elements.
Edit squaredme/SquaredME.F and uncomment the first line, i.e. take out the * in "*#define CHECK". Recompile and re-run the code which will now stop after the first evaluation of the matrix element and dump the kinematic invariants and the values of the tree- and loop-level matrix element.
Generate all code again from scratch. If that doesn't help, rename your Fortran code directory and generate everything (code + drivers) from scratch.

When running the examples, you get an error message like the following:

abbr_s.F: In subroutine `abbr_s':
     abbr_s.F:32:
            Opt30 =((4*Alfa2*(1 - 2*SW2)**2)/9.D0*
                                                 1
     abbr_s.F:33: (continued):
              -      Removed(Abb17)) -
                     2
     Arithmetic operator at (1) must operate on two subexpressions of
     arithmetic type, but the subexpression at (2) is not of arithmetic type

The example files (FormCalc/examples/*.m) are Mathematica programs, not Mathematica notebooks. Do not load them by saying "mathematica file.m". Rather, start Mathematica and type "<< file.m".

The Fortran code included in FormCalc is not intended as a final product. It has an exemplary character and the user is invited to understand and modify it.

Problem still there, want to submit a bug report?

Make sure you can reproduce the bug.
If you have another platform available, try to reproduce the bug there.
See if you can find a process similar to the one you're looking at in FormCalc's examples directory and compare your code with that.
Try to narrow down your problem as much as possible. Ideally, pinpoint a single line as the error locus. Unspecific bug reports which include 1 MByte of debugging output or such have essentially no chance of being answered.
If you have to send code, make reasonably certain that it will compile without having to fix the makefile. Do not use explicit private paths (e.g. home directory written out) in either Mathematica programs or Fortran code. (The logic is simple: the fewer things I have to do, the sooner you can expect an answer.)
Give details on the platform, compiler and Mathematica version. Be as specific as possible about the error. State what you have done and why you think the results are wrong.
By all means, send your Mathematica code as an ordinary Mathematica program (file.m), NOT as a Notebook (file.nb)!!!