GSLError, NaN and Minuit

ROOT
1

Hello everybody!

I have been using Minuit (Migrad/Simplex) through the ROOT::Math::Minimizer interface to find (minimizing Chi^2) the best fit parameters for a model function. The model function involves numerical integration. This is done by ROOT::Math::IntegratorOneDim::IntegratorOneDim (kADAPTIVESINGULAR).
However, there are points at which the integration fails with (: Error 18 in qags.c at 548 : cannot reach tolerance because of roundoff error and possibly also : Error 11 in qags.c at 543 : number of iterations was insufficient).
The integral just does not converge and there is hardly anything I could do about it. As far as I understand, the minimized function returns NaN to the fitter when this happens.
Nevertheless, the minimizer returns (quite good looking) results.
How exactly does Minuit handle this? Should (could) I do something about it. Are the results to be trusted?

Thank you.
Petr

2

Hi,

it can happen you have error in the integration routine due to problem with the integrand function. Normally the routine exists with an approximate values. You can try in some cases either to reduce the tolerances or increase the size of the number of iterations to get better results.
If the errors in the integration occur far away form the minimum, probably you can trust the result, since the minimization probably succeeded to adjust itself to a good function region.

However, if you get Nan as returned results, I am surprised the procedure converges.

You should maybe try to run also Migrad around the found minimum with Simplex to validate your result. If this is not possible, due to a problem with the function derivatives, I would then run at least a SCAN around the
minimum.

Best Regards

Lorenzo

3

Thanks for answer.
Where exactly can I adjust the max. number of iterations for the GSLIntegrator?

4

It is the “size” parameter used in the constructor. By default is defined to 1000. See

root.cern.ch/root/htmldoc/ROOT__ … Integrator

Lorenzo

5

Thanks for such a quick answer.

It changes the error messages a little bit:
Error in : Error 18 in qags.c at 548 : cannot reach tolerance because of roundoff error
Error in : Error 21 in qags.c at 553 : bad integrand behavior found in the integration interval

I discovered that the integration fails in regions of the parameter space that are not physically acceptable.
The problem disappears when I limit parameters so that the minimization routine stays within the “physical” parameter space.
I am not interested in the non-physical regions, so I only need to exlude them from the fit.
I know the relationship between the parameters that must be satisfied in order to stay within the physical space.
The only problem is how exactly could this be done.
It could have form of a simple check in the DoEval() function that would always look at the parameters to find out where the fitter/minimizer is going and in case it would be going into the forbidden region it would force the fitter/minimizer to try another way. Similarly some kind of “functional limits” would do (so I could say something like: “go from -10 to 10, but make sure that par1 < 2*sin(par2)”)…
Any ideas?

Thanks.

6

Hi,

unfortunately the only parameter constraints accepted in Minuit are simple ones, like A < parameter < B.
Sometimes, depending on the problem, there exists a transformation in the parameter, that can simplify the constraint.

Otherwise, a possibility is to add a penalty term to your minimization function. This is a term which grows as your values approaches the non physical-region. You can try by starting with something simple, for example
by adding a very large number to the function.

Cheers

Lorenzo

7

OK, so I basically do something like:

DoEval(pars) { if (pars[1] > 2*sin(par0)) { return "infinity"; } return chi^2(pars); }

It should make Chi^2 in the forbidden reagion unacceptably large and force the minizer to go somewhere else.

My only concern is this:
Does not this fool the algorithms that work with gradients (Migrad)? It introduces a huge gradient at the boundary that is actually not real.

Thanks.
Petr.

8

Hi,
you are right, for Migrad, if goes close to the boundary, this could cause a problem. I would not also use infinity, but a very large number, this also could make a problem.
Alternativly, you can try with a smoother function. A possibility, used in some constrained minimization methods, is to add a log term, in your case
something like:

  • K * log ( pars[1] - 2 * sin ( pars[0] ) ;

which gives infinity at the boundary condition. You must choose an appropriate value of K which does not affect too much the minimization in the good region.
Cheers

Lorenzo