-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPE fit algorithm: account for fit convergence to set valid status #106
Comments
Hi @tibaldo , sorry for the delay and thanks for this! |
Excellent, thank you. I'll make sure this is covered in the unit tests and make apull request probably tomorrow. |
So, discussing with @guillaumegrolleron , it seems he is already implementing these changes while working on #89 - where he is working on forcing the |
@guillaumegrolleron let me know how you want to proceeds, anything works for me |
While looking at he new implementation of the gain calibration via SPE fitting using run 3936, I found that for two pixels I got poor results with the fitted function not matching the data
Yet, the gain value is not flagged in the results file, that is, it has 'is_valid = True'.
By looking at the code it seems that presently the only condition to set 'is_valid = True' is that the fit algorithm returns some values. I think the fit convergence should be also taken into account to avoid this kind of problem.
I explored this is my branch tibaldo:spefit_convergence_issues and it seems rather straighforward. In this exemple of a possible implementation I checked three outputs from Minuit: fit convergence status, validity of parameters and that the parameters have not reached their limits.
What do you think @guillaumegrolleron @jlenain? If that seems like a good addition I can make any modifications needed and then make a pull request from my branch.
PS: I did not dig into the origin of the problem for the two pixels. For pixel 658 there is a failure in the preliminary Gaussian fits to set the starting value for the parameters, for pixel 660 the charge distribution looks unusual, but I'm unsure if it is just a plot range feature.
The text was updated successfully, but these errors were encountered: