Additional Trouble-shooting

When Minuit just doesn't work, some of the more common causes are:

• Precision mismatch. Make sure your FCN has been compiled with the same precision as the version of Minuit you are using. When using DOUBLE PRECISION, it is safest to use the IMPLICIT declaration to make sure that everything is DOUBLE PRECISION, not just the arguments of FCN but also the internal variables. Note that depending on the computer system used, floating-point constants may be passed as single precision in subroutine arguments, even if there is an IMPLICIT DOUBLE PRECISION statement (which is strictly speaking correct since the IMPLICIT statement refers only to variables, not constants). Therefore, if constants are used as arguments in subroutine calls, they must be explicitly of the right precision (for example, on Apollo, even 0. is not equal to 0.D0).

  If the problem is only one of precision, and not of word length mismatch, an appropriate [SET EPSmachine]SET EPS command may fix it.

• Trivial bugs in FCN. The possibilities for Fortran bugs are numerous. Probably the most common among physicists inexperienced in Fortran is the confusion between REAL and INTEGER types, which you can sometimes get away with, but not always. [For example, if A and B are REAL variables, the Fortran statement A = 2*B is not good programming, but happens to do what the user probably intended, whereas the statement A = B + 2/3 almost certainly will not do what the user intended.] Minuit can spot some trivial bugs itself, and issues a warning when it detects an unusual FCN behaviour. Such a warning should be taken seriously.

  Minuit also offers some tools (especially [SCAn]SCAN) which can help the user to find trivial bugs.

• Overwriting in a user routine. Overwriting most often occurs when setting the values of a local array or an array in COMMON, and elements outside the dimensions of the array are addressed. Most computer systems do not detect this error unless you attempt to write into a protected area of memory, and of course Minuit is also helpless, especially if Minuit itself is being overwritten. The symptoms of user overwriting may be almost anything, including unusual behaviour of Minuit itself. The effects depend critically on where instructions and data are loaded in memory, so they may change completely if the same program is recompiled with different compiler options or reloaded in a different sequence, even though the compiler and loader are not at fault.
• Changing the values of input arguments. In subroutine FCN, for example, the arguments NPAR and IFLAG, as well as the values of the parameters themselves, are only input to FCN and their values should not be changed inside FCN. Minuit is now protected against this in principle, since the user only gets a copy of the value, not the actual address of the internal Minuit variable, but still this is a symptom of misunderstanding by the user.

  If you really want to change the number of variable parameters, this must be done with commands like FIX and [RELease]RELEASE, by redefining parameters using command [PARameters]PARAMETER or [CLEar]CLEAR.

  Similarly, if a parameter takes on an unwanted value, it will do no good to change its value inside FCN: In the best case, Minuit won't see your improved value, and in the worst case, it will produce unpredictable results. To set a parameter to a certain value, use the command [SET PARameter]SET PARam, and to keep it within certain bounds, use the command SET LIMits. If the parameter must obey more complicated constraints, you must find a trick such as adding a penalty value to FCN outside of the physical region, to force it back to where you want it.

• An ill-posed problem. For questions of parameter dependence, see the discussion above on postive-definiteness. Other mathematical problems which can arise are: excessive numerical roundoff --- be especially careful of exponential and factorial functions which get big very quickly and lose accuracy; starting too far from the solution --- the function may have unphysical local minima, especially at infinity in some variables; incorrect normalization --- in likelihood functions, the probability distributions must be normalized or at least have an integral which is independent of the values of the variable parameters.
• A bug in Minuit. This is extremely unlikely, but it did happen once. If a bug is suspected, and all other possible causes can be eliminated, please try to save a copy of the input and output files, listing of FCN, and other information that may be relevant, and send them to JAMES at CERNVM or VXCERN::JAMES or JAMES\atsign CERNAPO.CERN.CH.