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

chConfig produced file not compatible #278

Closed giovanni-mocellin closed 4 years ago

giovanni-mocellin commented 4 years ago

Brief summary of issue

Running the analysis of scurves (in QC7 machine) produces now chConfig files that contain the column "mask" for the channels the booleans "True" and "False", instead of 1 and 0. This makes impossible a configuration with chConfig in QC8, since confAllChambers crashes requiring a number and not a boolean.

Types of issue

Expected Behavior

The chConfig files produced by the scurves analysis should have the "I:mask" column with numbers 0 or 1.

Current Behavior

The chConfig files produced by the scurves analysis now have the "I:mask" column with "False" or "True".

Steps to Reproduce (for bugs)

  1. Analyze an scurve with QC7 machine
  2. Check the chConfig file produced
  3. Look at the column "I:mask"

Possible Solution (for bugs)

Make sure that the code is writing the boolean for the mask as an integer number

Context (for feature requests)

When analyzing a single scurve, one can use "sed" command to change that and then anything that uses the chConfig works. But, if one tries to run the trimming, it might get stuck since it cannot configure the chambers with the chConfig derived from the previous scurve.

Your Environment

jsturdy commented 4 years ago

@giovanni-mocellin are the package versions (with git hash) the same on both machines? @AndrewLevin, was this a recent change that modified the format of the output file?

lpetre-ulb commented 4 years ago

I believe the issue is due to conversion from the % string formatting to the format() function as part of the GE2/1 generalizing PR:

https://github.com/cms-gem-daq-project/gem-plotting-tools/blob/bbc3e2531ac0c7c8b817768bc2f99f8dee9e9ab4/utils/scurveAlgos.py#L905-L913

Since the file chConfig is designed to be parsed by ROOT (as the header suggests), (all) the parameters should probably have an appropriate format_spec field.

jsturdy commented 4 years ago

@dteague do you think you could address this quickly? I guess all types should be numerical or string (though ROOT does support a boolean type, I'm not sure how/if pyROOT translates those...) In any event, the mask column is currently being specified with the I so it's trying to interpret it as an integer. It would be best to find all places where these csv TTree files are written and check with how they are read back, and just match the types

dteague commented 4 years ago

Looking into this now!