I am using Minuit2 via RooMinimizer instances algorithm in ROOT 6.18.
I went through the release notes and i have seen that few “fix” or “bug” have been fixed.
Being not an expert on this, can someone clarify what since then has been fixed on Minuit2 side?
Even just a list of JIRA tasks related to the bugs/issues solved and possible side effects of using a old version would be helpful, so i can figure out if i might be affected by this or not.
To be more specific , i found those changes about Minuit2 from release notes after root 6.18.
ROOT Version 6.24 Release Notes
I am not yet sure if they are really relevant for my case, i have to understand what the Minos() call does internally, since apparently it is flipping sometimes the error sizes and signs.
I also found reading some threads here in the forum that some bugs were found and fixed along the way.
In particular there seems to have been quite substantial fixes on Minos.
Are there bugs users should be aware ?
Thanks in advance
Renato
Edit:
To be clear on my issue: I have a fit with O(280) parameters and performing the LL scan over one parameter vs running Minos on the same parameter I get 2 different results on the central value and errors [trying to increase the granularity of the scan to be sure this is the case].
I am trying to debug what is going on with my code, which uses Minuit2 for the Minos call while the profile 1D is done with the automatic routines of createProfile , which configure the RooMinimizer without offsets, and not specifying Minuit2.
The FitResults seems to print that migrad, Hesse and Minos is successful .
If I remember well that committed fixed an issue when a new minimum was found while running Minos.
Suppose You run first Migrad and you get a certain minimum (x0, yval) where x0 is the minimum location and y0 the function value.
This can be a local minimum and it is possible that when scanning during the run of Minos you find a value y small than y0. In this case the solution needs to be updated and Migrad run again.
This is what is happening after this fix, so it is possible that you get new minimum values afterwards. However these values should have function values smaller than before. If this is not the case, then something else is playing a role, please let me know in this case
Thanks a lot Lorenzo.
Do I need also to understand that depending on when the Minos call finds a new minimum , prior to this fix I would also eventually get reported wrong errors?
Thank you Lorenzo.
Indeed probably i was affected by the bug, errors returned were meaningless. However the problem I had was that both Hesse and Minos (for just one parameter in my likelihood function) were executed removing all ranges on all nuisance parameters (450 in my fit) This triggers a new unphysical minima inside Minos, and Minos errors were unreliable as well the min.
I have validated afterwards my results with a likelihood profile through the RooProfileLL object.
( That said I also had issues there since I couldn’t control the RooMinimizer object used in root 6.18 so I had to overwrite the Root default minimizers and options to align my code to the one used to make the profile).
I am not sure I understand what has happened. Minuit does not remove the ranges, maybe there was some issues in the RooMinimizer, since you are using an old version, 6.18 ?
We were removing the ranges on parameters on purpose prior to run hesse and forget to reintroduce them when running MINOS. Then Minos was able to find a new minimum. I hope it’s clearer now.