Scurve fit failing to find good sigma

[giovanni-mocellin]

For a small number of channels (usually around 10 over the 3072 in a chamber), we can have the scurves fit that give an oddly small sigma, which is not physical (below 0.1 fC). Presentation link: https://indico.cern.ch/event/858083/contributions/3612746/attachments/1933512/3203223/Scurve_fitting_issue_-_Giovanni_Mocellin_-_25-10-2019.pdf

Types of issue

• Bug report (report an issue with the code)
• Feature request (request for change which adds functionality)

Expected Behavior

The scurve fit should be repeated in case we see that the scurve sigma is below 0.1 fC, because this is a clear indicator that the fit was failing. The width of the scurves is usually above 0.2 fC and also for those aforementioned channels, this is almost always the case. It can happen that the channels are disconnected due to a damaging discharge, so, in that case the sigma can be very small. Therefore, we can limit the trials that the fit can be performed before giving up.

Current Behavior

Scurve fit can give as a result a sigma below 0.1 fC even if the width is not even comparable to it.

Steps to Reproduce (for bugs)

1. Probably for every scurve scan of every chambers there are such channels...

Possible Solution (for bugs)

Put a condition on the scurve sigma calculated by the fit to have a new try in case it is below the boundary value (for a limited number of times).

Context (for feature requests)

Your Environment

qc8daq machine, standard scurve fit tools.

[jsturdy]

This issue is also designed to track improvements to the fitting across the board.
For the DAC scans we had discussed checking that the fit was sensible, using perhaps the chi2, or that the fit function is strictly monotonic in the fit range.

[AndrewLevin]

Hi Giovanni,

It does look like these channels can be fit from the 2D map, but can you send the path to the root file from that particular case such that we can check the 1D plots for those channels?

Thanks.

Andrew

[giovanni-mocellin]

Hi Andrew,

Example in channel 84, 85 of VFAT1 in path: /data/bigdisk/GEM-Data-Taking/GE11_QC8/GE11-X-S-INDIA-0017/scurve/2019.10.23.19.37/SCurveData

G

[AndrewLevin]

@giovanni-mocellin, I think the issue is related to the maxChi2 and it should be fixed in the pull request above, but actually, I wasn't able to reproduce the bad fits that you found in the first place. If you can give some details about what machine, software, and command you used to perform the fits, that would be helpful.

[giovanni-mocellin]

I used the qc8daq machine in the lab with the standard commands for taking and analysing the scurves. You can see when it was done by the scandate.

run_scans.py scurve 1 6 0x40
ana_scans.py scurve -s 2019.10.23.19.37 -c --chamberConfig --heavy

Probably the machine SW is not up-to-date to the last PRs... We always want to keep in the QC8 machine the SW that we are 100% sure that is reliable and it works for all the tasks... So we might be a bit behind...

[AndrewLevin]

The reason I could not reproduce the same bad fits as @giovanni-mocellin is actually not related to the software version, but because we are using random numbers initialized based on the process ID.

[lpetre-ulb]

I would have a more general question about the Scurve fitting.

Why are we fitting the Scurve? Couldn't the mean and standard deviation be directly extracted from the distribution? Indeed, since the Scurve is the convolution between a step function (the calibration pulse) and the noise (assumed Gaussian), deriving the Scurve would recover the original noise distribution shifted by the calibration pulse amplitude. If the noise distribution is assumed Gaussian, the parameters could be immediately extracted. The Gaussian fit might also be easier than modified error function fit. And if the noise is not Gaussian, the derivative would give information about the noise profile.

[AndrewLevin]

Well, we need to calculate the derivative somehow. There are probably too few points to use a finite different method -- there are typically like 5 points that are not 100 or 0. This is an example of what we are fitting for a case when the fit fails and succeeds:

Successful fit:

Failed fit:

[lpetre-ulb]

Thank you @AndrewLevin for your prompt reply. Indeed, I did not realize there are so few points between 0 and 100... This is also probably why the fits fail and must attempted multiple times with multiple initial conditions. Maybe that a finite difference method, although probably not precise enough for final analysis, would give better initial conditions than the one currently used? What do you think?

[AndrewLevin]

Yes, we could definitely set the initial conditions more intelligently. We are basically using a brute force method now where we try up to 30 fits with the mean incremented in steps and the noise set to random numbers.

[lpetre-ulb]

Moved to the new project on GitLab (gem-online-analysis#15) in order to make sure that such failed fits do not happen with the tools in development.