GstLAL issueshttps://git.ligo.org/lscsoft/gstlal/-/issues2024-02-22T09:28:12Zhttps://git.ligo.org/lscsoft/gstlal/-/issues/139Add units for request_memory in DAG layers2024-02-22T09:28:12ZPatrick GodwinAdd units for request_memory in DAG layersThere is a proposal for IGWN grid resources to require units for `request_disk` and `request_memory` in the near future, see https://git.ligo.org/computing/sccb/-/issues/1442.
The DAGs generated here don't currently specify units for `r...There is a proposal for IGWN grid resources to require units for `request_disk` and `request_memory` in the near future, see https://git.ligo.org/computing/sccb/-/issues/1442.
The DAGs generated here don't currently specify units for `request_memory` which will be an issue for online and offline analyses, example:
https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal/python/dags/layers/psd.py#L30
This can be changed from `2000` to `2000 MB` or `2 GB`.https://git.ligo.org/lscsoft/gstlal/-/issues/138cannot update gstlal:master container image because of broken/missing depende...2024-01-18T01:34:20ZPhilippe Grassiaphilippe.grassia@ligo.orgcannot update gstlal:master container image because of broken/missing dependencieslscsoft/gwistat builds containers upon containers.ligo.org/lscsoft/gstlal:master
This image is downrev on a lot (400+) packages. However, since early December the build fails on dnf update (https://git.ligo.org/ldas-cit/gwistat/-/jobs/...lscsoft/gwistat builds containers upon containers.ligo.org/lscsoft/gstlal:master
This image is downrev on a lot (400+) packages. However, since early December the build fails on dnf update (https://git.ligo.org/ldas-cit/gwistat/-/jobs/3080408)
For now the workaround to use ```dnf update -y --allowerasing --nobest``` seems sufficient to not block my progress, but allowing the package manager to install mismatched dependencies is not great.
to reproduce:
```docker run -it --entrypoint "" containers.ligo.org/lscsoft/gstlal:master /usr/bin/dnf update ```https://git.ligo.org/lscsoft/gstlal/-/issues/136gstlal_inspiral_calc_snr is broken?2023-11-09T00:59:42ZCody Messickgstlal_inspiral_calc_snr is broken?I tried running this command
`gstlal_inspiral_calc_snr --ht-gate-threshold 26.577 --mode 0 --data-source frames --channel-name H1=GDS-CALIB_STRAIN_CLEAN --channel-name L1=GDS-CALIB_STRAIN_CLEAN --frame-cache frame.cache --gps-start-tim...I tried running this command
`gstlal_inspiral_calc_snr --ht-gate-threshold 26.577 --mode 0 --data-source frames --channel-name H1=GDS-CALIB_STRAIN_CLEAN --channel-name L1=GDS-CALIB_STRAIN_CLEAN --frame-cache frame.cache --gps-start-time 1371865335 --gps-end-time 1371866235 --time-slide-file tisi.xml --reference-psd gstlal_coinc_G413610.xml --min-instruments 2 --svd-bank H1:H1-0861_GSTLAL_SVD_BANK-1368889884-604800.xml.gz,L1:L1-0861_GSTLAL_SVD_BANK-1368889884-604800.xml.gz --bank-number 1 --row-number 86 --outdir calc_snr_outdir --ranking-stat-output H1L1V1-0861_GSTLAL_DIST_STATS_CALC_SNR-1371866035-1.xml.gz --coinc-output H1L1V1-0861_GSTLAL_TRIGGERS_CALC_SNR-1371866035-1.xml.gz --start 1371866035 --end 1371866036 --verbose`
and got the following error
```
Traceback (most recent call last):
File "/usr/lib64/python3.6/site-packages/gstlal/pipeparts/sink.py", line 424, in new_sample_handler
return self.pull_buffers(elem)
File "/usr/lib64/python3.6/site-packages/gstlal/pipeparts/sink.py", line 463, in pull_buffers
self.appsink_new_buffer(elem_with_oldest)
File "/usr/lib64/python3.6/site-packages/gstlal/stream.py", line 230, in sample_handler
buf = self._pull_buffer(elem, caps=caps)
File "/usr/lib64/python3.6/site-packages/gstlal/stream.py", line 392, in _pull_buffer
data = pipeio.array_from_audio_sample(sample)
File "/usr/lib64/python3.6/site-packages/gstlal/pipeio.py", line 176, in array_from_audio_sample
a = numpy.frombuffer(mapinfo.data, dtype = numpy_dtype_from_caps(caps))
AttributeError: 'list' object has no attribute '__buffer__'
```
I'm assigning this to Kipp because his group wrote this code and I'm not sure who to assign it to. It's possible I did something wrong so it'd be nice if somebody else could confirm this issue.Kipp CannonKipp Cannonhttps://git.ligo.org/lscsoft/gstlal/-/issues/134gstlal and gstlal-ugly Debian dependency on libfftw3-3 - please break down to...2023-11-14T11:11:39ZSteffen Grunewaldgstlal and gstlal-ugly Debian dependency on libfftw3-3 - please break down to precisions for BookwormStarting with Bookworm (Debian 12, now "stable"), the `fftw3` source package no longer creates a `libfftw3-3` meta-package (up to Bullseye, that one depended on `libfftw3-double3, libfft3w-long3, libfftw3-single3` with identical version ...Starting with Bookworm (Debian 12, now "stable"), the `fftw3` source package no longer creates a `libfftw3-3` meta-package (up to Bullseye, that one depended on `libfftw3-double3, libfft3w-long3, libfftw3-single3` with identical version numbers).
`gstlal` and `gstlal-ugly` have a rather unspecific dependency on this (transitional) package instead of the precision-specific ones - the RPM `.spec` file instead lists plain `fftw`.
For the next releases, could the dependencies on `libfftw3-*` be more detailed so that builds for Bookworm are easier to accomplish? For the time being I had to create a meta-package with the right dependencies myself... Thanks!https://git.ligo.org/lscsoft/gstlal/-/issues/127gstlal-ugly devshm build failures on osx-642022-11-22T19:27:33ZPatrick Godwingstlal-ugly devshm build failures on osx-64```
libtool: compile: x86_64-apple-darwin13.4.0-clang++ -DPACKAGE_NAME=\"gstlal-ugly\" -DPACKAGE_TARNAME=\"gstlal-ugly\" -DPACKAGE_VERSION=\"1.10.0\" "-DPACKAGE_STRING=\"gstlal-ugly 1.10.0\"" -DPACKAGE_BUGREPORT=\"gstlal-discuss@ligo.or...```
libtool: compile: x86_64-apple-darwin13.4.0-clang++ -DPACKAGE_NAME=\"gstlal-ugly\" -DPACKAGE_TARNAME=\"gstlal-ugly\" -DPACKAGE_VERSION=\"1.10.0\" "-DPACKAGE_STRING=\"gstlal-ugly 1.10.0\"" -DPACKAGE_BUGREPORT=\"gstlal-discuss@ligo.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"gstlal-ugly\" -DVERSION=\"1.10.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PYTHON=\"3.9\" -DHAVE_LIBM=1 -DGSTLAL_FFTW_WISDOM_ENV=\"GSTLAL_FFTW_WISDOM\" -DGSTLAL_FFTWF_WISDOM_ENV=\"GSTLAL_FFTWF_WISDOM\" -DHAVE_NDS=1 -DHAVE_FRAMECPP=1 -DHAVE_FRAMECPP_2x=1 -DHAVE_GDS=1 "-DHAVE_WEBDIR=test \"x{HAVE_WEBDIR}\" == \"xyes\"" -I. -I$SRC_DIR/gst/gds -I$SRC_DIR/lib -D_FORTIFY_SOURCE=2 -isystem $PREFIX/include -mmacosx-version-min=10.9 -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -pthread -I$PREFIX/include -I$PREFIX/include/gstreamer-1.0 -I$PREFIX/include -I$PREFIX/include/gstreamer-1.0 -I$PREFIX/include -I$PREFIX/include/glib-2.0 -I$PREFIX/lib/glib-2.0/include -I$PREFIX/include -I$PREFIX/include/gstreamer-1.0 -I$PREFIX/include -I$PREFIX/include/glib-2.0 -I$PREFIX/lib/glib-2.0/include -I$PREFIX/include -I$PREFIX/include/gds -I$PREFIX/include/gds -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -fmessage-length=0 -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/gstlal-ugly-1.10.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -MT libgstgds_la-devshmsrc.lo -MD -MP -MF .deps/libgstgds_la-devshmsrc.Tpo -c $SRC_DIR/gst/gds/devshmsrc.cc -fno-common -DPIC -o .libs/libgstgds_la-devshmsrc.o
/Users/runner/miniforge3/conda-bld/gstlal-ugly_1668620014634/work/gst/gds/devshmsrc.cc:36:10: fatal error: 'sys/inotify.h' file not found
#include <sys/inotify.h>
^~~~~~~~~~~~~~~
mv -f .deps/libgstgds_la-lvshmsink.Tpo .deps/libgstgds_la-lvshmsink.Plo
1 error generated.
```
Looks like inotify isn't a thing for macOS, so one solution would be to conditionally build the devshm element based either on OS or on the presence of this header.Ron TapiaRon Tapiahttps://git.ligo.org/lscsoft/gstlal/-/issues/125gstlal_plot_psd_horizon importing deleted module2022-11-15T13:11:39ZDuncan Macleodduncan.macleod@ligo.orggstlal_plot_psd_horizon importing deleted moduleThe `gstlal_plod_psd_horizon` script in gstlal-1.10.0 is attempting to import a module that doesn't exist (has never existed?):
```console
$ gstlal_plot_psd_horizon --help
Traceback (most recent call last):
File "/home/duncan/opt/mamb...The `gstlal_plod_psd_horizon` script in gstlal-1.10.0 is attempting to import a module that doesn't exist (has never existed?):
```console
$ gstlal_plot_psd_horizon --help
Traceback (most recent call last):
File "/home/duncan/opt/mambaforge/conda-bld/gstlal_1668423852551/_test_env/bin/gstlal_plot_psd_horizon", line 26, in <module>
from gstlal.plots import horizon
ImportError: cannot import name 'horizon' from 'gstlal.plots' (/home/duncan/opt/mambaforge/conda-bld/gstlal_1668423852551/_test_env/lib/python3.10/site-packages/gstlal/plots/__init__.py)
```
The script is attempting to use the `HorizonDistance` object from that module. An object of that name is defined in `gstlal.psd` however it does not have the `from_psds()` classmethod that is used in `gstlal_plot_psd_horizon`.https://git.ligo.org/lscsoft/gstlal/-/issues/123GstLAL, GstLAL-Inspiral, and GstLAL-Burst missing requirements on matplotlib2023-06-16T13:05:30ZDuncan Macleodduncan.macleod@ligo.orgGstLAL, GstLAL-Inspiral, and GstLAL-Burst missing requirements on matplotlibGstLAL, GstLAL-Inspiral, and GstLAL-Burst all import matplotlib (or `mpl_toolkits`), but none of them have a formal requirement (in spec/debian) on Matplotlib. Can this please be added appropriately?GstLAL, GstLAL-Inspiral, and GstLAL-Burst all import matplotlib (or `mpl_toolkits`), but none of them have a formal requirement (in spec/debian) on Matplotlib. Can this please be added appropriately?Alexander PaceAlexander Pacehttps://git.ligo.org/lscsoft/gstlal/-/issues/121Migrate sbank usage to new standalone package2022-07-22T08:25:53ZDuncan Macleodduncan.macleod@ligo.orgMigrate sbank usage to new standalone packageThe SBank pipeline in lalsuite was deprecated in 2021, see https://git.ligo.org/lscsoft/lalsuite/-/commit/f2239c7c34d5538ddb30558393a862b79afac3b5 with a new standalone fork approved by SCCB earlier this year, see https://git.ligo.org/co...The SBank pipeline in lalsuite was deprecated in 2021, see https://git.ligo.org/lscsoft/lalsuite/-/commit/f2239c7c34d5538ddb30558393a862b79afac3b5 with a new standalone fork approved by SCCB earlier this year, see https://git.ligo.org/computing/sccb/-/issues/825. It would be great to see `gstlal-inspiral` migrate to the new standalone package from https://github.com/gwastro/sbank in time for O4.
The code is **the same**, just with some namespace changes, and further fixes to a number of bugs. I believe migrating would amount to:
- remove the `lalapps_cbc_` prefix from sbank executable calls
- remove the `lalinspiral.` python module prefix from imports
I would post a merge request to do this myself, but don't understand whether the existing INI files under `gstlal-inspiral/share/` should be updated, or left as a record of past analyses.https://git.ligo.org/lscsoft/gstlal/-/issues/117gstlal-inspiral 1.9.2, 1.9.3, 1.10.0, 1.11.0 fails to build on Ubuntu Focal2023-11-14T11:07:14ZSteffen Grunewaldgstlal-inspiral 1.9.2, 1.9.3, 1.10.0, 1.11.0 fails to build on Ubuntu Focal`gstlal-inspiral` build segfaults in the doc stage. Apparently a `doxygen` issue:
```
# grep doxy *.log
...
Preparing to unpack .../132-doxygen_1.8.17-0ubuntu2_amd64.deb ...
Unpacking doxygen (1.8.17-0ubuntu2) ...
Setting up doxygen (1.8...`gstlal-inspiral` build segfaults in the doc stage. Apparently a `doxygen` issue:
```
# grep doxy *.log
...
Preparing to unpack .../132-doxygen_1.8.17-0ubuntu2_amd64.deb ...
Unpacking doxygen (1.8.17-0ubuntu2) ...
Setting up doxygen (1.8.17-0ubuntu2) ...
checking for doxygen... /usr/bin/doxygen
checking doxygen is at least version 1.8.3... yes
/usr/bin/doxygen Doxyfile
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
Generating codemake[2]: *** [Makefile:588: doxyfile.stamp] Segmentation fault (core dumped)
configure:11720: checking for doxygen
configure:11738: found /usr/bin/doxygen
configure:11750: result: /usr/bin/doxygen
configure:11762: checking doxygen is at least version 1.8.3
ac_cv_path_DOXYGEN=/usr/bin/doxygen
DOXYGEN='/usr/bin/doxygen'
```
Is there a remedy?
The full log file: [gstlal-inspiral_1.9.2-1+ubuntu20.04.0_amd64.--pbuilderlog](/uploads/7a7f247c428a6a95880630fe306ddaaa/gstlal-inspiral_1.9.2-1+ubuntu20.04.0_amd64.--pbuilderlog)https://git.ligo.org/lscsoft/gstlal/-/issues/116segments.py mistakenly creates 2ifo jobs for 1ifo time2024-02-14T17:24:19ZRyan Mageesegments.py mistakenly creates 2ifo jobs for 1ifo timeWhen a large stretch of time is analyzed at once, we break it up into more manageable segments. At present, these artificial boundaries can coincide with the time an IFO switches off. This leads to the creation of (for example) 2 IFO job...When a large stretch of time is analyzed at once, we break it up into more manageable segments. At present, these artificial boundaries can coincide with the time an IFO switches off. This leads to the creation of (for example) 2 IFO jobs in 1 IFO time; at the very least, this will cause reference psd jobs to persistently fail since it will try to write a 'None' time series to disk. We need to add some extra logic to prevent segmenting along existing segment boundaries in this module:
https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal/python/segments.py
As a simple way to reproduce, filter over all of O1 at once and try to run the psd job that starts at gps time: 1127634250.https://git.ligo.org/lscsoft/gstlal/-/issues/114Update sim inspiral table to support new waveform parameters2022-04-21T01:21:24ZChad HannaUpdate sim inspiral table to support new waveform parametersPROPOSAL: We will change sim_inspiral definitions to reflect the new essential and optional arguments here:
- https://git.ligo.org/waveforms/o4-injection-file/-/blob/main/OPTIONAL_SPEC.json
- https://git.ligo.org/waveforms/o4-injection-...PROPOSAL: We will change sim_inspiral definitions to reflect the new essential and optional arguments here:
- https://git.ligo.org/waveforms/o4-injection-file/-/blob/main/OPTIONAL_SPEC.json
- https://git.ligo.org/waveforms/o4-injection-file/-/blob/main/ESSENTIAL_SPEC.json
We will need updates here:
- https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal/gst/lal/gstlal_simulation.c#L272
- https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal/gst/lal/gstlal_simulation.c#L505
And for reference here are some LAL links:
- https://git.ligo.org/lscsoft/lalsuite/-/blob/master/lalsimulation/lib/LALSimInspiralWaveformParams.c#L70Kipp CannonKipp Cannonhttps://git.ligo.org/lscsoft/gstlal/-/issues/109Should gstlal-burst now rely on gstlal-inspiral? Related to gstlal-burst test...2024-02-09T11:10:40ZPatrick GodwinShould gstlal-burst now rely on gstlal-inspiral? Related to gstlal-burst test failuresSee https://git.ligo.org/lscsoft/gstlal/-/jobs/1829467 for an example, with snippet below:
```
==================================== ERRORS ====================================
_______________ ERROR collecting python/cherenkov/rankingsta...See https://git.ligo.org/lscsoft/gstlal/-/jobs/1829467 for an example, with snippet below:
```
==================================== ERRORS ====================================
_______________ ERROR collecting python/cherenkov/rankingstat.py _______________
python/cherenkov/rankingstat.py:45: in <module>
from gstlal.stats import trigger_rate
E ImportError: cannot import name 'trigger_rate'
```
This is failing specifically because `gstlal-burst` does not have a dependency on `gstlal-inspiral`, but this module (as of https://git.ligo.org/lscsoft/gstlal/-/commit/0c928579021cfcc1fb817d72634783d9b2d1bf25) now depends on `gstlal-inspiral`. Should this be the case?
/cc @kipp.cannon, @soichiro.kuwaharahttps://git.ligo.org/lscsoft/gstlal/-/issues/108rocky linux 8 package dependencies.2022-03-31T14:21:27ZAlexander Pacerocky linux 8 package dependencies.This ticket is to track dependencies for `gstlal` that are not currently packaged for Rocky Linux 8. I'm dropping a link to the RL8 `gstlal-dev` container pipeline, since this is relevant to that project as well.
https://git.ligo.org/a...This ticket is to track dependencies for `gstlal` that are not currently packaged for Rocky Linux 8. I'm dropping a link to the RL8 `gstlal-dev` container pipeline, since this is relevant to that project as well.
https://git.ligo.org/alexander.pace/gstlal-dev/-/tree/rocky
I'm searching for available or installed packages on `ldas-pcdev8`, or in my RL8 `igwn-opt` container in which I have the following repos active:
```
[root@a8e5c9fe7386 python-bottle]# yum repolist
repo id repo name
appstream Rocky Linux 8 - AppStream
baseos Rocky Linux 8 - BaseOS
epel Extra Packages for Enterprise Linux 8 - x86_64
epel-modular Extra Packages for Enterprise Linux Modular 8 - x86_64
extras Rocky Linux 8 - Extras
lscsoft-production lscsoft-production
lscsoft-production-7-src lscsoft-production-7 (source)
powertools Rocky Linux 8 - PowerTools
```
Note the `lscsoft-production-7-src` repo is there on the chance that the source rpm is available and just needs to be rebuild for RL8.
I'm putting in a table below of missing package dependencies, and what it's being blocked by. It's possible that the dependency's dependency could be blocked, but i'm leaving that as an exercise for lscsoft's koji instance. These were obtained by some combination of building packages and/or `yum-builddep`.
| Package | Missing Dependencies | Notes |
| ------ | ------ | ------ |
| `lalinference` | `python3-gwpy`, `python3-healpy` | https://git.ligo.org/alexander.pace/gstlal-dev/-/jobs/1824004 |
| `lalapps` | `lalinference` | |
| `numpy` | ? | `python3-numpy` is available. but just `numpy` (installed in SL7) isn't available on RL8? |
| `python36-gobject-devel` | | might be the same as `pygobject3-devel`, available in powertools |
| `gds-lsmp-devel` | | https://git.ligo.org/sccb/requests/-/issues/847 |
| `gds-framexmit-devel` | | https://git.ligo.org/sccb/requests/-/issues/846 |
| `nds2-client-devel` | | source from `lscsoft-production-7-src` rebuilds in RL container with error |
| `nds2-client-headers` | |source from `lscsoft-production-7-src` rebuilds in RL container with error |
| `python36-ligo-scald` | `python3-bottle`| https://git.ligo.org/sccb/requests/-/issues/856 |
I'll update this table and make notes as dependencies get resolved.Alexander PaceAlexander Pacehttps://git.ligo.org/lscsoft/gstlal/-/issues/106Cannot run 4 detectors test analysis because some program do not support K12022-02-10T02:12:32ZChiWai ChanCannot run 4 detectors test analysis because some program do not support K1Specifically, https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/bin/gstlal_inspiral_injection_snr and https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/python/stats/inspiral_lr.py#L555 uses hard-coded info...Specifically, https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/bin/gstlal_inspiral_injection_snr and https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/python/stats/inspiral_lr.py#L555 uses hard-coded information for doing calculation and they cause some jobs fails for 4 detectors (H1, L1, V1, K1) analysis with injection jobs.
Tracing back the failed jobs, it appears that [gstlal_inspiral_injection_snr](https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/bin/gstlal_inspiral_injection_snr) computes the injection SNRs using PSDs and hard coding them into `alpha4` <-- H1, `alpha5` <-- L1, and `alpha6` <-- V1 of the SimInspiralTable, and then these injection SNRs are being used in [this line](https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/python/stats/inspiral_lr.py#L555) for simulating the numerator of the LR. However, I believe `alphaX` is not supposed to be used for injection SNRs, so it suggests that it's not just hard coding problem but a design problem.
To solve this problem properly, kipp suggested two solutions:
1. don't pre-compute these numbers in SimInprialTable, move this calculation to where it is needed and compute the numbers on-the-fly
2. correct the table structure (SimInprialTable) so that it can accommodate the desired instruments (preferred)
It would be great for people to know this problem and discuss about potential solutions.
*Related information: https://git.ligo.org/waveforms/o4-injection-file/-/tree/main*https://git.ligo.org/lscsoft/gstlal/-/issues/104Horizon distance label is wrong on summary page2022-02-09T09:24:49ZChad HannaHorizon distance label is wrong on summary pageThis claims to still use 1.4/1.4 binary, but now that things are per bin, I think the legend is wrong??
![image](/uploads/e7e3f7703fdcd1e75d7770ec141f5d60/image.png)This claims to still use 1.4/1.4 binary, but now that things are per bin, I think the legend is wrong??
![image](/uploads/e7e3f7703fdcd1e75d7770ec141f5d60/image.png)https://git.ligo.org/lscsoft/gstlal/-/issues/100plot_mc_vt_injections fails on master2022-01-18T13:45:59ZChad Hannaplot_mc_vt_injections fails on masterTo reproduce this, follow instructions from here:
https://lscsoft.docs.ligo.org/gstlal/cbc_analysis.html
I have run two separate dags so I think this is real (note they use a singularity container hence the `/usr` prefix.)
```
Traceba...To reproduce this, follow instructions from here:
https://lscsoft.docs.ligo.org/gstlal/cbc_analysis.html
I have run two separate dags so I think this is real (note they use a singularity container hence the `/usr` prefix.)
```
Traceback (most recent call last):
File "/usr/bin/gstlal_inspiral_make_mc_vtplot", line 130, in <module>
injs += lsctables.SimInspiralTable.get_table(ligolw_utils.load_filename(injection_file, contenthandler = LIGOLWContentHandler, verbose = options.verbose))
File "/usr/lib64/python3.6/site-packages/ligo/lw/utils/__init__.py", line 427, in load_filename
with open(filename, "rb") as fileobj:
FileNotFoundError: [Errno 2] No such file or directory: '/ligo/home/ligo.org/chad.hanna/development/half_res_offline_dag/bns_injections.xml'
```
The strange thing is that the file does exist:
```
[chad.hanna@comp-hd-002 logs]$ ls -ltrh /ligo/home/ligo.org/chad.hanna/development/half_res_offline_dag/bns_injections.xml
-rw-rw-r--. 1 chad.hanna chad.hanna 1.3M Jan 10 18:58 /ligo/home/ligo.org/chad.hanna/development/half_res_offline_dag/bns_injections.xml
```
So I am not sure if it is an issue with the DAG dependency, condor file transfer, or what, but its a thing.Hiroaki OhtaHiroaki Ohtahttps://git.ligo.org/lscsoft/gstlal/-/issues/98GstLAL container should include sphinx tools needed to build documentation (i...2022-01-12T15:19:58ZChad HannaGstLAL container should include sphinx tools needed to build documentation (if possible)Following the writeable container based installation here:
https://lscsoft.docs.ligo.org/gstlal/installation.html
mostly works great, however the containers don't contain sphinx, e.g.,
```
Singularity> pwd
/ligo/home/ligo.org/chad.han...Following the writeable container based installation here:
https://lscsoft.docs.ligo.org/gstlal/installation.html
mostly works great, however the containers don't contain sphinx, e.g.,
```
Singularity> pwd
/ligo/home/ligo.org/chad.hanna/development/gstlal-dev/src/gstlal/doc
Singularity> make
# FIXME FIXME FIXME total hack to work around unique python packaging
if [ 0 = 0 ]; then \
mv ../gstlal/python/__init__.py ../gstlal/python/__init__.py.bk; \
fi
sphinx-apidoc -e -o source/gstlal/python-modules ../gstlal/python ../gstlal/python/misc.py ../gstlal/python/bottle.py ../gstlal/python/coherent_null.py ../gstlal/python/matplotlibhelper.py
make: sphinx-apidoc: Command not found
make: *** [gstlal-modules] Error 127
```Alexander PaceAlexander Pacehttps://git.ligo.org/lscsoft/gstlal/-/issues/95Ensure that all installation options have fully optimized code2021-11-18T12:25:05ZChad HannaEnsure that all installation options have fully optimized codeLooking at the instructions here:
https://lscsoft.docs.ligo.org/gstlal/installation.html#install-source
There is no mention of optimization. This is an issue only if these methods do not by default produce optimized code. Anyone doing...Looking at the instructions here:
https://lscsoft.docs.ligo.org/gstlal/installation.html#install-source
There is no mention of optimization. This is an issue only if these methods do not by default produce optimized code. Anyone doing large scale testing on the LDG **without** optimized code is looking for a world of pain. Possible problems include
1. Running 2-4 times slower (this means taking a month instead of a week)
2. Using twice as much RAM (this could be the difference of jobs being queued or not)
All methods listed except for building by source need to by default use optimized code suitable for all architectures. This makefile serves as our reference for reasonable optimization:
- https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/share/post_O3/optimized/Makefile.ligosoftware_gcc_deps
- https://git.ligo.org/lscsoft/gstlal/-/blob/master/gstlal-inspiral/share/post_O3/optimized/Makefile.ligosoftware_gcc_gstlalAlexander PaceAlexander Pacehttps://git.ligo.org/lscsoft/gstlal/-/issues/93Remove `fpconst` in favor of `numpy`2022-08-23T14:44:20ZPatrick GodwinRemove `fpconst` in favor of `numpy`Example in `gstlal_inspiral`, but in many other places throughout:
```python
try:
from fpconst import PosInf
except ImportError:
# fpconst is not part of the standard library and might not be
# available
PosInf = float("+inf")
```
...Example in `gstlal_inspiral`, but in many other places throughout:
```python
try:
from fpconst import PosInf
except ImportError:
# fpconst is not part of the standard library and might not be
# available
PosInf = float("+inf")
```
NaN, +/- inf can all be leveraged through numpy at this point.Kipp CannonKipp Cannonhttps://git.ligo.org/lscsoft/gstlal/-/issues/92Assertion Failed: gstlal_Itacac2021-12-03T02:14:15ZChiWai ChanAssertion Failed: gstlal_Itacac## Analysis
S5 re-analysis injection DAGs, chunk 3
## Problem
The following assertion has failed:
```
ERROR:gstlal_itacac.c:990:process: assertion failed: (itacacpad->samples_available_for_padding == 0 || samples_left_in_window == it...## Analysis
S5 re-analysis injection DAGs, chunk 3
## Problem
The following assertion has failed:
```
ERROR:gstlal_itacac.c:990:process: assertion failed: (itacacpad->samples_available_for_padding == 0 || samples_left_in_window == itacacpad->n)
```
## Reproducing the problem
You can reproduce the same assertion failure by copying the directory:
```
/home/chiwai.chan/itacac_assert_failed
```
at CIT and run the `runme.sh` script. Below are the code version that we used for the re-analysis.
### Code version
* lalsuite: master branch @ commit
https://git.ligo.org/lscsoft/lalsuite/-/commit/fdfeb41846998aa3ec68004ebb09be63909bb9de
aka "Merge branch 'snglcoinc_work' into 'master'"
```plaintext
$ git checkout fdfeb41846998aa3ec68004ebb09be63909bb9de
```
* GstLAL:
[mcvt_plus_fastpath](https://git.ligo.org/lscsoft/gstlal/-/tree/mcvt_plus_fastpath)
branch (master from \~early April 2021 with patches) @ commit
https://git.ligo.org/lscsoft/gstlal/-/commit/44608390328c9518834e047b846f61001ed6f463
aka "make_mc_vtplot: add note"
```plaintext
$ git checkout 44608390328c9518834e047b846f61001ed6f463
```
## Others
As Chad has pointed out, the bug might share the same origin with this bug: https://git.ligo.org/lscsoft/gstlal/-/issues/82Cody MessickCody Messick