RooMinimizer convergance problem for a chi^2 function with 200 params

Dear RooFit expert,

I am encountering some instability in the convergence of a custom chi^2 function with approximately 200 parameters while running a RooMinimizer with strategy(2).

Here’s a summary of my observations:

  • When running the fit with all parameters starting from their expected best-fit values and using Minuit2 strategy 2, approximately 1 out of 4 to 5 fits returns a status of 0. To address this, I implemented a simple while loop:

while (mini->minimize("Minuit2")!=0) { mini->clearStatusHistory(); }
this loop provides a stable result, with every ~4 to 5 iterations.

  • Alternatively, when fixing one of the nuisance parameters (NP) to be prefit/postfit 1 sigma away from the best-fit value and using mini->minimize("Minuit2","migrad") , the convergence is significantly worse. I’m still utilizing the same while loop as above, which never terminates.

I have attached the workspace and the custom header for the function. Please note that access to the server for evaluating the function requires being within the CERN gateway, such as lxplus.

Below is a simple recipe to reproduce the issue:

root [1] gInterpreter->ProcessLine("#include \"customPdfs.h\"");
root [2] RooAbsPdf* testpdf=w->pdf("testpdf");
root [3] RooMinimizer *mini=new RooMinimizer(*testpdf);
root [4] mini->setStrategy(2);
root [5] mini->optimizeConst(1);
root [6] RooRealVar *alpha_JET_Flavor_Composition = w->var("alpha_JET_Flavor_Composition");
root [7] alpha_JET_Flavor_Composition->setVal(1);
root [8] alpha_JET_Flavor_Composition->setConstant(1);
root [9] while (mini->minimize("Minuit2","migrad")!=0) {mini->clearStatusHistory();}

workspace.root (29.9 KB)
customPdfs.h (12.8 KB)


Hi Huacheng,

Thanks for the interesting post.
This is an extreme case, for which I’d like to involve @jonas .


Hi @huachengcai92,

it seems that the starting values are far off the Minimum in a region where the functions second derivatives are not positive. This can be seen in the log:

Info in <Minuit2>: NegativeG2LineSearch Doing a NegativeG2LineSearch since one of the G2 component is negative

This step of finding a better starting point with the NegativeG2LineSearch is very time consuming and doesn’t always work. I would try manually to find a better starting value.

In general, these warnings are unexpected:

   The distance from the minimum cannot be estimated, since the minimized
   function seems not to be strictly convex in the space probed by the fit.
   That is expected if the starting parameters are e.g. close to a local maximum
   of the minimized function. If this function is expected to be fully convex
   in the probed range or Minuit is already close to the function minimum, this
   may hint to numerical or analytical issues with the minimized function.
   This was found by projecting the difference of gradients at two points, s0 and p1,
   onto the direction given by the difference of s0 and p1, where:
 * s0:  	[     -0.191787733    -0.7734663273   -0.03914202044   -0.09341585612  -0.002726139702                0    0.05968969823                0   -0.05219929238     -0.107620217....    -0.02006176846]	
 * p1:  	[    -0.1917827944    -0.7734662623    -0.0391409347   -0.09338966811  -0.002726139702                0    0.05967447822                0   -0.05219898974    -0.1076205587....     -0.0199845435]	
 * gradient at s0:  	[     -1.457814566     -3.224587821    -0.5791219045     -0.960725049                0                0                0                0    -0.6924981307     -1.226542945....       6.968780385]	
 * gradient at p1:  	[                0                0                0    -0.9703322995   -0.06894850788                0                0                0    -0.4752723722     -1.287870092....        11.9569593]	
   To understand whether this hints to an issue in the minimized function,
   the minimized function can be plotted along points between s0 and p1 to
   look for unexpected behavior.

Seems that even near the Minimum, the function is not strictly convex. So before making more guesses here, let’s think about why that is maybe. You wouldn’t expect this for a chi2-function, right? It should be parabolic in all parameters, no? Are you expecting that your function is actually not strictly convex?

Also, does this problem happen is you use less parameters than 200? Is there some threshold when it suddenly becomes problematic?

Another side note: your custom function should not be a RooAbsPdf, because it is not a PDF but a NLL/Chi2 function. Functions should inherit from RooAbsReal, not RooAbsPdf. Because it’s also possible here that the RooAbsPdf’s auto-normalization capabilities are playing tricks on you here, since a chi2 function should not be normalized.


Hi @jonas ,

Many thanks for the detailed response!

Your insights are very helpful. I made some initial investigations by plotting the chi^2 function on POI frames. Here’s what I discovered:

  • In the global minimum region, all functions are strictly convex. That is as expected and indeed we find that global minimization is okay.

  • However, one parameter, cptb, has two local minimums. I attached two plots, one is in the ± 1 sigma region, and another is zoomed into a smaller x-range. As you can see, cptb has a Higgs-potential-like shape. I guess this will cause an issue when we try to evaluate the impact of NPs, when cptb is being pulled to the negative direction, between two local minimums…

Regarding using RooAbsReal, it’s indeed a good point. However, I created this object via RooGenericPdf as

RooGenericPdf testpdf{"testpdf", expression, {vars}};

where expression is a self-defined string. Is there an easy way to cast RooAbsPdf into RooAbsReal (aka disable toe automatic normalization?) I tried with

RooAbsReal* testpdf=w->pdf("testpdf");

but it is still doing the normalization…
cptb_zoomed.pdf (14.8 KB)
cptb.pdf (14.7 KB)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.