Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue processing certain (strictly-not-LIGO-style) channel names #335

Open
Nikhil-Mukund opened this issue Jun 16, 2022 · 2 comments
Open

Comments

@Nikhil-Mukund
Copy link

Nikhil-Mukund commented Jun 16, 2022

The summary page generation functions assume the channel names are strictly LIGO style. The naming convention is mostly likely hard-coded into the HTML page generation functions. For example, plots for G1:ISC-LSC_SRC_FP is processed correctly, while G1:LSC_SRC_EP-P does not work. GWPy can, however, fetch data from both channels without any issues.

link-to-sample-gwsumm-page-with-issue

Steps to reproduce the issue at Caltech LDAS machines

## Activate conda environment
source /cvmfs/oasis.opensciencegrid.org/ligo/sw/conda/etc/profile.d/conda.sh
conda activate igwn-py38
## Call gw_summary from command line
gw_summary gps 1272110951 1272110961 -v -D -i G1 -f /path-to-config/sample-config.ini   -o /home/albert.einstein/public_html/GEO600/summary

sample-confile.ini file:

; -----------------------------------------------------------------------------
;; GWSumm G1 sample configuration
;;
;
;; -----------------------------------------------------------------------------
;
;
[html]
GEO-base = https://ldas-jobs.ligo.caltech.edu/~albert.einstein/GEO600/summary/
issues = https://git.ligo.org/detchar/ligo-summary-pages/issues

[tab-SRC-overview]
name = Signal Recycling Cavity
parent = SRC
shortname = Summary

1 = G1:LSC_SRC_OAN timeseries
1-ylim = -15,15
1-all-data = True
1-ylabel = 'Voltage [counts]'
1-title = 'G1 SRC OAN'

2 = G1:ISC-LSC_SRC_FP timeseries
2-all-data = True
2-ylabel = 'Voltage [counts]'
2-title = 'G1 SRC FP'

3 = G1:LSC_SRC_EP-P timeseries
3-all-data = True
3-ylabel = 'Voltage [counts]'
3-title = 'G1 SRC EP QUAD'

4 = G1:LSC_SRC_FP-MSR timeseries
4-all-data = True
4-ylabel = 'Voltage [counts]'
4-title = 'G1 SRC FP MSR'


[G1:LSC_SRC_OAN]
frametype = R

[G1:ISC-LSC_SRC_FP]
frametype = R

[G1:LSC_SRC_EP-P]
frametype = R

[G1:LSC_SRC_FP-MSR]
frametype = R

; -----------------------------------------------------------------------------
@shivarajkandhasamy
Copy link

shivarajkandhasamy commented Sep 30, 2022

This is actually coming fom the parsing function (split_combination in channel.py) that extracts the channel names from a list of channels given for a plot. It splits the string when it encounters not an alpha-numeric or an underscore character. Since the channels are separated by gammas this works well for standard naming convention (usually gamma breaks the string, exception are types of trend data).

The hyphen (-) in the GEO frames also breaks this requirement and hence the parsing function picks up only part of the channel name and the frame reading code not able to find that channel in the frames. A simple fix would be to add hyphen also in the allowed characters. For example, changing the line 38 in gwsumm/channels.py from,

r'(?:[-_][a-zA-Z0-9_]+)?'
to
r'(?:[-_][a-zA-Z0-9_-]+)?'

would work. I tested it and it works. Here is the link to a test page I produced.

@Nikhil-Mukund
Copy link
Author

That's great!! Thanks, @Shivaraj17, for solving the issue. I cloned the igwn-py36 environment, modified line 38 in gwsumm/channels.py as above, and launched gw_summary (at LDAS-PCDEV ). The code ran successfully and produced the test pages (link) without any issues.

gw_summary gps -v -i G1 -f /home/albert.einstein/path-to-config/sample-config.ini -o /home/albert.einstein/public_html/GEO600/summary 1272110953 1272110963

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants