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

SBitRate scan produces wrong VFAT threshold configuration #286

Closed mexanick closed 4 years ago

mexanick commented 4 years ago

Brief summary of issue

During the QC7 execution the CFG_THR_ARM for VFATs 0 and 1 of GE11-X-S-INDIA-0012 were assigned to 0 causing the final s-curves to fail. The initial (CFG_THR_ARM_DAC = 100) s-curves are alright and can be found at /data/bigdisk/GEM-Data-Taking/GE11_QC8/GE11-X-S-INDIA-0012/scurve/2020.02.03.14.59/SCurveData

The SBit rate scan data is here: /data/bigdisk/GEM-Data-Taking/GE11_QC8//sbitRate/channelOR/2020.02.03.16.16 and its analysis is here: /data/bigdisk/GEM-Data-Taking/GE11_QC8/GE11-X-S-INDIA-0012/sbitRate/channelOR/2020.02.03.16.16/

The summary canvas plot shows nothing weird for VFAT0 and VFAT1, the inflection point table also looks reasonable with non-zero numbers:

| Geo Addr   |   VFAT Number |   ARM DAC Inflection Pt |
|------------+---------------+-------------------------|
| (2, 3, 0)  |             0 |                      12 |
| (2, 3, 0)  |             1 |                      13 |
| (2, 3, 0)  |             2 |                      12 |
| (2, 3, 0)  |             3 |                      12 |
...

However vfatConfig.txt has zeros threshold assigned to VFAT0 and VFAT1:

vfatN/I:vt1/I:trimRange/I
0   0   0
1   0   0
2   38  0
3   26  0
...

Types of issue

Expected Behavior

Reasonable threshold values should be produced for all VFATs

Current Behavior

Unphysical threshold values are produced during the analysis

Steps to Reproduce (for bugs)

Run analysis on the sbitRate data obtained on Feb.3rd 2020 @16:16: ana_scans.py sbitThresh -i /data/bigdisk/GEM-Data-Taking/GE11_QC8//sbitRate/channelOR/2020.02.03.16.16/SBitRateData.root --chamberConfig -m 100 -d

Context (for feature requests)

As a result of the problem described above, last step of QC7 testing receives a corrupted input and provide unphysical results, leading the test to fail and potential replacement of good FE components.

Your Environment

lpetre-ulb commented 4 years ago

Actually, the code works as designed. It finds the first THR_ARM_DAC for which the Sbit rate is below the configured cut value:

https://github.com/cms-gem-daq-project/gem-plotting-tools/blob/e86ae2a09c843b917540f4a6648860ae47d0b20f/utils/threshAlgos.py#L1458-L1465

However, in this scan, the Sbit rate is already zero when the THR_ARM_DAC is zero:

Canvas_1

The solution would probably to require a maximum in the Sbit rate first.

AndrewLevin commented 4 years ago

Or we can start the sbitRate scan at ARM DAC = 10 instead of 0, using --scanmin. Probably there is some kind of overload when you set it to 0.

mexanick commented 4 years ago

This is weird... The issue is only observed on VFATs 0 and 1, the other VFATs are showing normal results. Shifting the starting point to 10 is not the best decision in my opinion. This number is arbitrary and actually can mask a real problem. Indeed, scanning from 0 to max, finding the rate maximum and requiring the rate to fall under specified limit later is a solution. Another (and possibly more robust) is to start from the max DAC value and go lower and lower until the rate limit is reached. Such approach will also save as from the issues when we have non-monotonic rate curve.

mexanick commented 4 years ago

/data/bigdisk/users/mdalchen/qc7_elog230.txt

lpetre-ulb commented 4 years ago

Analysis routine fixed in https://github.com/cms-gem-daq-project/gem-plotting-tools/pull/287.