The ana_scans.py tool is extremely out of date. It will need significant updating. Many analysis routines have completely changed or need updates to how they are handled. In some cases scan analysis tools are not even present in the tool.
[x] Feature request (request for change which adds functionality)
Expected Behavior
The ana_scans.py tool should be updated to accommodate subparsers similar to how run_scans.py works. There should be a subparser that corresponds to each of the following tools:
anaDACScan.py,
anaSBitMonitor.py,
anaSBitReadout.py,
anaSBitThresh.py,
anaUltraLatency.py,
anaUltraScurve.py,
anaUltraThreshold.py,
anaXDAQLatency.py
In all cases the subparser should take at minimum an input scandate argument. Additionally all subparsers should take a set of mutually exclusive arguments:
chamberConfig, The detectors listed in chamber_config should be used,
inputFile, here is a one or two column file that gives the correspondence between detectors and geographic address and for each entry the code will look if a scandate argument is present.
cNameAndAddr, here is a string which gives the detector serial number and geographic address at the time of the scan
chamberName, here is a string which gives the detector serial number; it will be assumed any geographic address in the input file matches this name.
In the case of scans that put multiple detectors worth of information in the outputfile (e.g. dacScanV3.py, sbitThreshScanParallel.py) the mutually exclusive argument will be used to map the geographic address to a detector name.
The following subparsers should enable the possibility for analysis in parallel:
anaSBitMonitor.py, and
anaUltra*.py.
If a particular scan application requires a series of calibration coefficients this should be determined from a DB query.
Current Behavior
ana_scans.py is broken.
Context (for feature requests)
Right now the QC8 shift team has been writing one off scripts to serially analyze different scan routines and this is taking a lot of time. This should be addressed to decrease the turnaround from calibration scan to plot.
Additionally there are a lot of bells and whistles that are needed for some tools and it would be easier if the $USER did not need to worry about this.
bdorney
commented
5 years ago
Brief summary of issue
The
ana_scans.pytool is extremely out of date. It will need significant updating. Many analysis routines have completely changed or need updates to how they are handled. In some cases scan analysis tools are not even present in the tool.Supercedes issues:
Types of issue
Expected Behavior
The
ana_scans.pytool should be updated to accommodatesubparserssimilar to howrun_scans.pyworks. There should be a subparser that corresponds to each of the following tools:anaDACScan.py,anaSBitMonitor.py,anaSBitReadout.py,anaSBitThresh.py,anaUltraLatency.py,anaUltraScurve.py,anaUltraThreshold.py,anaXDAQLatency.pyIn all cases the subparser should take at minimum an input
scandateargument. Additionally all subparsers should take a set of mutually exclusive arguments:chamberConfig, The detectors listed inchamber_configshould be used,inputFile, here is a one or two column file that gives the correspondence between detectors and geographic address and for each entry the code will look if ascandateargument is present.cNameAndAddr, here is a string which gives the detector serial number and geographic address at the time of the scanchamberName, here is a string which gives the detector serial number; it will be assumed any geographic address in the input file matches this name.In the case of scans that put multiple detectors worth of information in the outputfile (e.g.
dacScanV3.py,sbitThreshScanParallel.py) the mutually exclusive argument will be used to map the geographic address to a detector name.The following subparsers should enable the possibility for analysis in parallel:
anaSBitMonitor.py, andanaUltra*.py.If a particular scan application requires a series of calibration coefficients this should be determined from a DB query.
Current Behavior
ana_scans.pyis broken.Context (for feature requests)
Right now the QC8 shift team has been writing one off scripts to serially analyze different scan routines and this is taking a lot of time. This should be addressed to decrease the turnaround from calibration scan to plot.
Additionally there are a lot of bells and whistles that are needed for some tools and it would be easier if the
$USERdid not need to worry about this.Your Environment