search

cms-gem-daq-project / gem-plotting-tools

Repository for GEM commissioning plotting tools
GNU General Public License v3.0
1 stars 26 forks source link

in calibrateThrDac.py, Gaussian fits can fail #208

Closed AndrewLevin closed 5 years ago

AndrewLevin commented 5 years ago

The Gaussian fit to the scurveMean distribution can fail, and there is currently no protection against this.

Brief summary of issue

In calibrateThrDac.py, a Gaussian is fitted to the per-vfat scurveMean distribution in order to determine the mean of the scurveMean distribution and the width of the scurveMean distribution. The Gaussian fit can fail, and it fails visibly in at least the 7 cases below. GE11-X-L-CERN-0002_2019 03 04 21 45_4_25 0 GE11-X-L-GHENT-0002_2019 01 16 18 35_11_30 0 GE11-X-L-GHENT-0002_2019 01 16 18 35_23_30 0 GE11-X-S-BARI-0012_2018 12 05 22 06_23_40 0 GE11-X-S-BARI-0012_2018 12 05 22 38_3_60 0 GE11-X-S-CERN-0012_2018 08 10 18 47_18_150 0 GEB3c-l1-w_2018 11 05 12 04_21_150 0

Types of issue

Possible Solution

I would propose that, in calibrateThrDac.py, we remove points that satisfy scurveMeanError/scurveMean < 0.001. Also, we may want to look into how these histograms/tgraphs are binned in the scurve analysis script.

Context (for feature requests)

In VFAT18 in the plot below, the error on the highest THR_DAC point is around 6*10^-7, which causes the fit to visibly fail because that point is weighted to highly.

canvScurveMeanVsThrDac_Summary 11 old

The solution above removes this point, and then the fit looks reasonable.

canvScurveMeanVsThrDac_Summary 11

Your Environment

bdorney commented 5 years ago

In this particular case why is the fit range not modified? e.g. it seems to still be trying to include that part of the DAC. Isn't the fit range automatically determined? The polynomial seems a bit "bendy" as a result of trying to use this range.

Additionally what about the failures reported here. Ignoring VFATs where the scurve data was actually bad, e.g. slide 4 VFAT7, there are cases where a single point is weighting the fitting; or there are cases where the scurve mean vs. ARM DAC curve is completely missing the low ARM DAC range; this is problematic and we should try to address this.

AndrewLevin commented 5 years ago

My proposal is to remove the point, which is equivalent to modifying the fit range. The algorithm already does remove some bad points, but not points that are bad in this way.

This issue is not related to the failures reported in Federica's slides.

I can create a separate issue for that, or should I consolidate both issues?

bdorney commented 5 years ago

My proposal is to remove the point, which is equivalent to modifying the fit range.

I'm not sure it is the same thing. In your example above you have removed the point, but the fit is still allowed to be in that region (see above). While I agree we should remove the point, in this case since the point is at the edge of the range we should also reduce the range.

I can create a separate issue for that, or should I consolidate both issues?

Separate issue is a good idea.

AndrewLevin commented 5 years ago

Yes, the fit range could be automatically set to the minimum and the maximum unremoved points. That would not affect the fitted coefficients, but would affect the plots.

Here is the separate issue: https://github.com/cms-gem-daq-project/gem-plotting-tools/issues/210

bdorney commented 5 years ago

Yes, the fit range could be automatically set to the minimum and the maximum unremoved points. That would not affect the fitted coefficients, but would affect the plots.

Let's do that.