cms-gem-daq-project / sw_utils Goto Github PK

Brief summary of issue

Right now calibrateArmDac.sh takes an scurve and then analyzes the scurve and then moves to the next arm dac set point.

This in principle slows down the data acquisition and blocks a CTP7 for a longer period of time than necessary. It would be good if the script first took all the data and then afterward analyzed all the data (possibly in parallel) in two separate loops, rather than in one main loop.

Types of issue

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

Expected Behavior

See above.

Current Behavior

See above.

Context (for feature requests)

Reduces time a CTP7 cannot be used for other tasks.

Your Environment

• Version used: d16c709

Brief summary of issue

At the moment, it is possible to change the symlinks for chConfig and vfatConfig if an scurve or an sbitThreshold scan is taken.
If a trim run is taken, it is presently not possible to get a symlink for the chConfig.txt derived from the trimmed scurve taken at the end of the procedure. So it would be nice to have the tool updateConf.py with an option for trim runs.

Types of issue

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

Expected Behavior

updateConf.py with an option in order to be able to change the symlinks for chConfig.txt in the folder $DATA_PATH/configs for trim runs. Perhaps, a '-t' option...

Current Behavior

updateConf.py has -c (chConfig = from scurve) and -v (vfatConfig = from sbitThresh) options only.

Steps to Reproduce (for bugs)

Possible Solution (for bugs)

Context (for feature requests)

Your Environment

QC8 DAQ machine.

• Version used:
• Shell used:

Brief summary of issue

Instructions to access the CMS databases outside of CERN have been written to the GEM DAQ Expert TWiki page. Since the guide is the GEM software reference, a link should point to the TWiki section.

Types of issue

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

Expected Behavior

A link should point to the TWiki page. But where? This is sysadmin job and there is no section dedicated how to setup a DAQ machine.

Context (for feature requests)

Using the upstream GEM software requires access to the CMS database. Since the databases are not accessible from outside the CERN GPN, a tunnel must be setup.

Your Environment

• Version used: 08ecb25

Brief summary of issue

It would be great if all log files and final calibration results where located in:

${DATA_PATH}/${DETECTOR}/armDacCal/scandate

Where scandate would be the datetime when the script either launched, or finished.

It should also make a current symlink.

Types of issue

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

Expected Behavior

Central location for output log files and calibration results as described above.

Current Behavior

Output log files are located in the calling directory and the output calibration files are found in $ELOG_PATH.

Context (for feature requests)

Quality of life feature.

Brief summary of issue

NSFD error when trying to make rpm reg_utils

Types of issue

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

Expected Behavior

Current Behavior

"error: File not found by glob:"

Steps to Reproduce (for bugs)

1. environment variables: export ELOG_PATH=<repo directory>/elogs; export BUILD_HOME=<repo directory>; export PETA_STAGE=/data/bigdisk/sw/peta-stage/;
2. enter python virtual environment: source <repo directory>/venv/cc7/py2.7/bin/activate
3. cd <repo directory>/reg_utils/
4. make rpm
   my repo directory is: /afs/cern.ch/work/w/wvetens/private/cms-gem-daq/
   error message: error: File not found by glob: /afs/cern.ch/work/w/wvetens/private/cms-gem-daq/reg_utils/python/reg_interface/rpm/build/bdist.linux-x86_64/rpm/BUILDROOT/reg_interface-1.1.0-1.2879f89git.centos7.python2.7.x86_64/usr/lib/python*/site-packages/reg_utils/scripts/*.py

Possible Solution (for bugs)

It looks like everything up to usr exists. I tried creating a link to my /usr folder, which seems to have all the needed directories, but it looks like the makefile overwrites this before looking for usr. Looks like I'm either missing an environment variable not talked about in the readme or you can insert something like mkdir $BUILD_HOME/reg_utils/python/reg_interface/rpm/build/bdist.linux-x86_64/rpm/BUILDROOT/reg_interface-1.1.0-1.2879f89git.centos7.python2.7.x86_64/usr; ln -s /usr $BUILD_HOME/reg_utils/python/reg_interface/rpm/build/bdist.linux-x86_64/rpm/BUILDROOT/reg_interface-1.1.0-1.2879f89git.centos7.python2.7.x86_64/usr before the step where it searches for this. I couldn't find where in the makefile to do this however, as it is rather terse.

Context (for feature requests)

Your Environment

• Version used:
• Shell used: bash

Brief summary of issue

Occasionally sourcing setup_gemdaq.sh kills ssh session:

% source sw_utils/scripts/setup_gemdaq.sh -p $PWD/venv
ERROR: You must use "source sw_utils/scripts/setup_gemdaq.sh" to run this script.











Connection to gem904qc8daq closed.

Here the script did not realize it was being source'd and then it killed the ssh session. A subsequent login and call succeeded:

% ssh -XtY <username>@gem904qc8daq
% source sw_utils/scripts/setup_gemdaq.sh -p $PWD/venv
source $PWD/venv/cc7/py2.7/bin/activate
(py2.7) %

Types of issue

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

Expected Behavior

Should recogonize it's being source'd and if not it should not kill the ssh session.

Current Behavior

Doesn't always recognize it's being source'd and then when it doesn't it kills the ssh session.

Steps to Reproduce (for bugs)

1. Login to a 904 DAQ machine
2. source sw_utils/scripts/setup_gemdaq.sh -p $PWD/venv

Appears to happen ~50% of the time.

Possible Solution (for bugs)

Should use return here instead of exit:

This will resolve the killing an ssh session. However why it doesn't recognize it's being sourced is beyond me.

Context (for feature requests)

Script should recognize it's being source'd

Your Environment

• Version used: 07036f5
• Shell used: /bin/zsh

Brief summary of issue

Right now calibrateArmDac.sh only dumps VFAT0 configuration to log file. This is a problem because:

1. This VFAT could be masked, and
2. The DAC values of each VFAT could be different (e.g. after DAC scans).

Types of issue

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

Expected Behavior

All VFAT settings are written to log file.

Current Behavior

Only VFAT0 is written to log file.

Possible Solution (for bugs)

This line should be executed inside of a loop over all VFATs:

Context (for feature requests)

For evaluating scan settings it is important to have all info in the log file.

Brief summary of issue

Documentation needs to be updated to inform user about improvements to replace_parameter.sh made in cms-gem-daq-project/gemctp7user#38.

Types of issue

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

Expected Behavior

Under Configuration File on CTP7 describe how replace_parameter.sh can be used to take a file input from anaDACScan.py or manually made by the user (e.g. when providing CFG_IREF) to update the VFAT configuration files.

The user should be reminded of this again under the Configuring a Detector Section.

Current Behavior

$USER doesn't know about replace_parameter.sh

Context (for feature requests)

$USER doesn't know about useful QOL feature.

Brief summary of issue

Due to known issues in the make process rpms or pip packages should never be built from inside a $VIRTUAL_ENV. We should add a subsection/warning/readily readable statement under the Building GEM Software section of the guide to explicitly state this.

Types of issue

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

Expected Behavior

Should explicitly state that you should not build inside a VENV.

Current Behavior

From the commands shown it's implied that you should not build from inside a VENV (e.g. if you follow the commands verbatim you would never enter a virtual environment).

Context (for feature requests)

New developers have issues when attempting to build packages because documentation is not clear, e.g. #38. The problem is not the developer here but the documentation for lacking this key statement.

Your Environment

• Version used:
• Shell used: