chConfig produced file not compatible

[giovanni-mocellin]

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

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

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

• Machine used: qc7daq machine
• Shell used: bash

[jsturdy]

@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]

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

gem-plotting-tools/utils/scurveAlgos.py

Lines 905 to 913 in bbc3e25

	for chan in range(0, maxChans):
	confF.write('{0}\t{1}\t{2}\t{3}\t{4}\t{5}\t{6}\n'.format(
	vfat,
	dict_vfatID[vfat],
	chan,
	trim_list[vfat][chan],
	trimPolarity_list[vfat][chan],
	masks[vfat][chan],
	reason4Mask[vfat][chan]))

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]

@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]

Looking into this now!