sBitRate scan analysis not working with GLIB

[cgalloni]

The script to analyze the root file of an sBitThresh scan taken with the GLIB fails with the error:

Traceback (most recent call last):
  File "/opt/cmsgemos/bin/ana_scans.py", line 909, in <module>
    args.func(args)
  File "/opt/cmsgemos/bin/ana_scans.py", line 113, in anaSBITThresh
    scandate = args.scandate)
  File "/usr/lib/python2.7/site-packages/gempython/gemplotting/utils/threshAlgos.py", line 1502, in sbitRateAnalysis
    if dict_dacInflectPts[dacName][ohKey][vfat][0] == None:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Brief summary of issue

The script to analyze the root file of an sBitThresh scan taken with the GLIB fails. This might be related to the fact that for VFAT 0 and 1 the rate at CFG_THR_ARM_DAC 0 is 0, reported in [#286]

Types of issue

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

Expected Behavior

It should produce the output files with the results of the analysis

Current Behavior

ana_scans.py sbitThresh -i /data/bigdisk/GEM-Data-Taking/GE11_QC8///sbitRate/channelOR//2020.02.12.11.33/SBitRateData.root --chamberConfig -m 100
Analyzing: /data/bigdisk/GEM-Data-Taking/GE11_QC8///sbitRate/channelOR//2020.02.12.11.33/SBitRateData.root
Loading info from input TTree
Looping over stored events in rateTree
Determine when SBIT rate falls below 100.0 Hz and writing output data
| Geo Addr   |   VFAT Number |   ARM DAC Inflection Pt |
|------------+---------------+-------------------------|
| (2, 3, 0)  |             0 |                       4 |
| (2, 3, 0)  |             1 |                       3 |
| (2, 3, 0)  |             2 |                       4 |
| (2, 3, 0)  |             3 |                       3 |
| (2, 3, 0)  |             4 |                       3 |
| (2, 3, 0)  |             5 |                       6 |
| (2, 3, 0)  |             6 |                       4 |
| (2, 3, 0)  |             7 |                       3 |
| (2, 3, 0)  |             8 |                       2 |
| (2, 3, 0)  |             9 |                       2 |
| (2, 3, 0)  |            10 |                       3 |
| (2, 3, 0)  |            11 |                       3 |
| (2, 3, 0)  |            12 |                       3 |
| (2, 3, 0)  |            13 |                       2 |
| (2, 3, 0)  |            14 |                       3 |
| (2, 3, 0)  |            15 |                       2 |
| (2, 3, 0)  |            16 |                       3 |
| (2, 3, 0)  |            17 |                       4 |
| (2, 3, 0)  |            18 |                       2 |
| (2, 3, 0)  |            19 |                       2 |
| (2, 3, 0)  |            20 |                       6 |
| (2, 3, 0)  |            21 |                       2 |
| (2, 3, 0)  |            22 |                       2 |
| (2, 3, 0)  |            23 |                       3 |
Traceback (most recent call last):
  File "/opt/cmsgemos/bin/ana_scans.py", line 909, in <module>
    args.func(args)
  File "/opt/cmsgemos/bin/ana_scans.py", line 113, in anaSBITThresh
    scandate = args.scandate)
  File "/usr/lib/python2.7/site-packages/gempython/gemplotting/utils/threshAlgos.py", line 1502, in sbitRateAnalysis
    if dict_dacInflectPts[dacName][ohKey][vfat][0] == None:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Steps to Reproduce (for bugs)

1. log as: gemuser@gem904qc7daq
2. testConnectivity.py 2 3 0x1 --skipDACScan --skipScurve --checkCSCTrigLink
3. run_scans.py sbitThresh 2 3 0x01 --waitTime 2
4. ana_scans.py sbitThresh -i /data/bigdisk/GEM-Data-Taking/GE11_QC8///sbitRate/channelOR//2020.02.12.11.33/SBitRateData.root --chamberConfig -m 100

Possible Solution (for bugs)

Context (for feature requests)

Your Environment

• Version used:
• Shell used: bash

[AndrewLevin]

@bregnery, this is related to the inflection point finder

[bregnery]

I will take a look, but there is a bit more information that I need. @cgalloni What version of numpy was used during this? I have found that there are syntax changes between older and new versions of numpy that caused similar errors in the past.

[cgalloni]

Thanks @bregnery, this is the version on the machine from what I see

Python 2.7.5 (default, Jun 20 2019, 20:27:34) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.version.version 
'1.16.0'