RooFit: Access MINOS STATUS=(SUCCESSFUL/PROBLEMS/FAILURE)?

Hi,

In a RooFitResult I can access the Minos status via RooFitResult::status(). However, this value always seems to be 0. Searching through the source code, I found out why: The logic is simple (and to me somewhat absurd). If asymmetric errors for at least one parameter can be calculated, the status will always be 0. This, on the other hand, means that only if all asymmetric errors fail, the MINOS status will be != 0. In my experience, I have never seen a half-decent fit, where there is not at least one parameter for which asymmetric errors can be estimated (unless you are doing something really, really stupid).

So, to me, the MINOS status as returned by a RooFitResult has no practical use at all. It would be more useful to only get a 0 if all parameter’s asymmetric errors are estimated finely.

However, MINOS prints in its status output the result of the MINOS step more sophisticated (SUCCESSFUL: all asymmetric errors fine, PROBLEMS: at least one parameter with problems, FAILURE: all parameters with problems). As I am conducting mass fits and do not want to grep through MINUIT output, is there a way to get more information from the MINOS step at RooFit level?

Hi Florian,

You are completely right of course. The main issue is that status() report the status of the last operation.
However, as of ROOT 5.32 it is possible to retrieve the status of each step with the status history interface

inline UInt_t numStatusHistory() const { return _statusHistory.size() ; }
Int_t statusCodeHistory(UInt_t icycle) ;
const char* statusLabelHistory(UInt_t icycle) ;

whre numStatusHistory() will return you the number of status codes available and statusCodeHistory()
gives you the code of each state and statusLabelHistory() gives you the description of each step.
This should help you to retrieve more useful information on your fit,

Wouter

Hi Wouter,

yes, I am aware of that and I agree that this is a good improvement. Nevertheless, there might be fits where MIGRAD and HESSE are happy, but MINOS still ends in PROBLEMS (mainly because one of the asymmetric errors for one or more parameters could not be determined). This also leads to a MINOS status of 0. Looking at the RooFitResult, this fit will look just like one without any problems. In a mass fit situation like a toy study, one cannot check every fit in detail and therefore having estimates on how many fits ended with MINOS STATUS=PROBLEMS could indicate problems.

I found a workaround, though, in which I check all asymmetric errors in the RooFitResult. If some are zero, MINOS must have ended in PROBLEMS. However, I am not sure if this is sufficient or if there are other scenarios, where MINOS might have failed on some parameters although all asymmetric errors are != 0.

Cheers,

Florian

Hi Florian,

Thanks for the detailed explanation - I might have partially misunderstood your initial comment.

This mapping between MINOS reporting errors and raising a non-zeri status flag is something that
is controlled inside MINOS, which is outside my control. You might want to try Minuit2
(just add Minimizer(“Minuit2”) to the command line) which seems to have a better error reporting
than the old MINOS implementation (from my experience - but this is not systematically checked)

Wouter

[quote=“Wouter Verkerke”]This mapping between MINOS reporting errors and raising a non-zeri status flag is something that is controlled inside MINOS, which is outside my control. You might want to try Minuit2
(just add Minimizer(“Minuit2”) to the command line) which seems to have a better error reporting
than the old MINOS implementation (from my experience - but this is not systematically checked)[/quote]

Thanks for pointing out Minuit2. It does not help much with my original problem (i.e. MINOS will still return 0 in any case where it is not epically failing on all parameters, as far as I see). But nevermind.

Another question comes to my mind. After a few tests, it seems to me that Minuit2 is always performing faster than Minuit (factor 2-3) and generally has less problems than Minuit (e.g. faster converging compared to Minuit where MIGRAD has problems converging and MINOS forces convergence, finds new minimum, etc.; less p.d.f. value … warnings/errors).

However, RooFit by default still uses Minuit. So there must be a catch with Minuit2? What is the reason for still using Minuit? Can I switch to Minuit2 for all my fits or are there known problems, where Minuit is to be preferred? Or is Minuit2 just not tested as well as Minuit?