Hello,
Thank you for trying with the new version. It is then worth investigating further why are you getting these wrong sign errors.
I would suggest you doing the following:
when running the Migrad minimisation use a lower print out level (e.g minimizer.SetPrintLevel(2)),
increase then the print level to 3 only when running Minos for these problematic parameter (e.g. parameter 59). Do not run even Minos for the other parameter or keep a low print level.
capture the output using tee in a file by doing:
root -l -i myScript.C 2>&1 | tee output.log
Then please send me the file or a link to the file if it is too big, so I can inspect and try to understand exactly what is happening. Unfortunately I could not reproduce this behaviour with any of the example code I have tried.
Thanks for these suggestions. I have re-run as youâve described, at a print level of 2 when in Migrad and at a print level of 3 when running Minos. Minos is run only for parameters 59, 88, and 94. If you search for âMINOS: Parâ in the output, which I have uploaded as a tar.gz file on Google drive, youâll find the three locations where Minos finishes the calculation of errors for these parameters.
Hello,
Thank you for uploading the file. I could get it and I will investigate. This has been a useful exercise and we need to improve the logging for scaling in case of large number of parameter fits.
Cheers
Lorenzo
Thanks Lorenzo. Iâm looking forward to hearing about anything that you find.
Would you be able to summarize what bug was fixed in Minos related to a similar problem last year? I know that youâd mentioned above that something in Minos was fixed in the most recent versions of ROOT. I would be interested to see if I could understand that bug, just to know if itâs related to my latest problem or not.
The fix was for the case when by performing a searches for the lower/upper error a new global function minimum was found. This does not seem to be the case.
The problem is really weird, I do not see anything with Minos, but looking at the output I see some weird result obtained. In the attached plot you see the profile likelihood scan obtained by Minos for lower and upper error. The scanned points do not seem to be consistent with the found minimum point (blue point). The dashed read line is the parabola approximation used to compute the parabolic error on the parameter 59.
I think a good test , would be to perform again a full profile likelihood scan for this parameter (parameter 59) in the [0, minimum + 2* sigma] range, computing like 50 points and see what is happening. This means performing for each point a Minimization fixing parameter 59 to one of the grid point. Could you please do this check ?
That graph does look strange indeed. I would be happy to perform the test that you indicated. I might have missed it, however, is what youâre asking easily accomplished using one of the built-in functions within ROOT::Math::Minimizer with Minuit2 or does this require me to actually perform 50 individual fits in a loop?
Apologies that this took a couple of days. Please find attached the scan of template_59 that you requested. Does this stand out as unusual to you at all? It doesnât look very surprising to me, but maybe Iâve missed something.
Is there anything else that I can do to help figure this out?
Thank you for producing this plot.
The plot makes sense given the minimum found, but I do not understand the lower scan obtained for parameter 59. Probably something is wrong in the minimization in this case, maybe one local minimum of the function. In this case it is anyway clear that the lower error for that parameter is the distance from the minimum to the bound. The upper error seems to be correctly estimated.
Yes, what I think is happening is that when running a Minos scan, all the other parameter, apart the one we scan, e.g. parameter 59, are moved to a different initial value depending on the off-diagonal covariance matrix element. I presume that in case of being close to a lower bound and with many parameters these value might be not fully correct, and therefore the subsequent minimization might end up in some local minima.
It seems to me you are also not running Hesse after Migrad. Maybe is something worth trying to run before Minos.
Calling Hesse after the minimization finishes partially solves the problem. Parameter 88 and 94 now do not have a negative errLow value, but parameter 59 still does. That is one out of 100 parameters still failing in Minos, though Minos isnât aware of its own failure.
Hi,
This is good. In the case of parameter 59 you can always perform a profile likelihood scan as the figure above, which confirms you that the error is just the distance from the lower bound.
Cheers
Lorenzo
