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

Update calibrateThrDac.py to use nonliner fit function #184

Closed bdorney closed 5 years ago

bdorney commented 5 years ago

Brief summary of issue

Linear fit applied for calibration of CFG_THR_ARM_DAC should be dropped in favor of a nonlinear fit function.

The DAC itself is nonlinear at low DAC values and also at high DAC values. High DAC values are not the concern, however if the fit curve doesn't accurately describe the data the trimming procedure will fail to align the channels.

See discussion on slides 11 & 16

Types of issue

Expected Behavior

Fit function should accurately describe the data, especially at the DAC values where the DAC is most useable.

Current Behavior

Fit function only describes the DAC in the linear range.

Context (for feature requests)

Linear fit of the dac calibration causes the trim algorithm to fail if a particular VFAT should be trimmed in this region (e.g. noise is low enough for DAC to be placed in this region).

Your Environment

bdorney commented 5 years ago

@AndrewLevin do you think you could tackle this by next Wednesday?

AndrewLevin commented 5 years ago

Yes, I will do it by next Wednesday.

AndrewLevin commented 5 years ago

Can you point me to some data to test the updated fitting function?

bdorney commented 5 years ago

See:

https://github.com/cms-gem-daq-project/sw_utils/issues/18

bdorney commented 5 years ago

Don’t overwrite the existing data if you can avoid it.

AndrewLevin commented 5 years ago

With a fifth order polynomial I get

canvscurvemeanvsthrdac_summary_quinticfittingfunction

instead of

canvscurvemeanvsthrdac_summary_linearfittingfunction

Does it look good?

bdorney commented 5 years ago

But how does it look at low values of ARM DAC? e.g. in range 20 to 80. The high range is the less useful range and we wouldn't really operate there (cuts the signal).

Can you show a zoom in the requested region; also a data/fit would be interesting to see.

AndrewLevin commented 5 years ago

In the data that you provided in https://github.com/cms-gem-daq-project/sw_utils/issues/18, there is basically no nonlinearity in the region 20 to 80. Here is the zoom of the data and a linear fit in that region: canvscurvemeanvsthrdac_summary

bdorney commented 5 years ago

Why don't you try to investigate further with the other recent measurements. See for example the cases returned by:

ls $DATA_PATH/*/armDacCal/current
bdorney commented 5 years ago

Also it would be good if the algorithm could try to identify when it should stop fitting; and use a per VFAT fit range rather than a common fit range applied to all hybrids on a link.

The algorithm should stop fitting when the ARM DAC setting puts the comparator such that it is sensitive to the pedestal (you can see this in the scurve mean vs. arm DAC when at low arm DAC in some of the above plots the scurve mean point jumps up). To determine when it should stop fitting as a first approach I think it should look when the ENC (e.g. scurve sigma) starts to blow up, e.g. deviate significantly from the high ARM DAC ENC value; this would be a good place to stop. There might be a better approach; I'm interested in what you find.

AndrewLevin commented 5 years ago

There are 6 listOfScanDates files, two of them contain scandates that do not exist ($DATA_PATH//GE11-X-S-CERN-0009/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-CERN-0010.txt and $DATA_PATH//GE11-X-S-CERN-0010/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-CERN-0009.txt), one of them ($DATA_PATH//GE11-X-L-CERN-0002/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-L-CERN-0002.txt) seems to have a data format problem:

Info in ROOT::Math::ParameterSettings>: lower/upper bounds outside current parameter value. The value will be set to (low+up)/2 
Info in ROOT::Math::ParameterSettings>: lower/upper bounds outside current parameter value. The value will be set to (low+up)/2 
Traceback (most recent call last):
  File "calibrateThrDac.py", line 229, in <module>
    mapVFATPos2VFATSN[vfat]['serialNum'] = array_vfatData[array_vfatData['vfatN'] == vfat]['vfatID']
TypeError: Cannot cast array data from dtype('float32') to dtype('uint32') according to the rule 'safe'

and the other three ($DATA_PATH//GE11-X-S-CERN-0007/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-CERN-0007.txt, $DATA_PATH//GE11-X-S-BARI-0006/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-BARI-0006.txt, and $DATA_PATH//GE11-X-S-INDIA-0007/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-INDIA-0007.txt seem to have basically negligible nonlinearities especially if you take the error bars seriously:

canvscurvemeanvsthrdac_summary_ge11-x-s-bari-0006

canvscurvemeanvsthrdac_summary_ge11-x-s-cern-0007

canvscurvemeanvsthrdac_summary_ge11-x-s-india-0007

bdorney commented 5 years ago

one of them ($DATA_PATH//GE11-X-L-CERN-0002/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-L-CERN-0002.txt) seems to have a data format problem:

Issue is that bit flips occur when the chipID is requested from the VFAT and then is beyond what an integer of type long can hold which is all the array class can hold and so a hot fix was applied to change it to a float. You'll have to force it during debugging sessions. Hopefully the Reed-Muller encoded hybrids will make this point mute.

and the other three ($DATA_PATH//GE11-X-S-CERN-0007/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-CERN-0007.txt, $DATA_PATH//GE11-X-S-BARI-0006/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-BARI-0006.txt, and $DATA_PATH//GE11-X-S-INDIA-0007/armDacCal/current/listOfScanDates_calibrateArmDac_GE11-X-S-INDIA-0007.txt seem to have basically negligible nonlinearities especially if you take the error bars seriously:

See the PM I sent you for another trial. The range of nonlinear is different for each hybrid and the issue here is the fringe cases.

Also how's the automatic determination of fit range coming?

AndrewLevin commented 5 years ago

I just made a pull request to address this issue: https://github.com/cms-gem-daq-project/gem-plotting-tools/pull/186