lalsuite merge requestshttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests2023-11-30T20:37:38Zhttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2226Draft: Use RTLD_DEEPBIND when importing the LAL SWIG library2023-11-30T20:37:38ZDuncan Macleodduncan.macleod@ligo.orgDraft: Use RTLD_DEEPBIND when importing the LAL SWIG library### Description
This MR attempts to resolve widely-seen issues using the LAL SWIG bindings for a version of LAL linked against FFTW in an environment where the `libblas` implementation is linked against MKL.
In this scenario you regula...### Description
This MR attempts to resolve widely-seen issues using the LAL SWIG bindings for a version of LAL linked against FFTW in an environment where the `libblas` implementation is linked against MKL.
In this scenario you regularly see things like this:
```python
>>> import numpy
>>> import lal
>>> lal.CreateForwardREAL8FFTPlan(512, 1)
XLAL Error - XLALCreateREAL8FFTPlan (/home/conda/feedstock_root/build_artifacts/lal-split_1698222321355/work/lib/fft/RealFFT_source.c:120): Generic failure
XLAL Error - XLALCreateForwardREAL8FFTPlan (/home/conda/feedstock_root/build_artifacts/lal-split_1698222321355/work/lib/fft/RealFFT_source.c:136): Internal function call failed: Generic failure
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Internal function call failed: Generic failure
```
The issue is that, when `numpy` is imported _first_, the FFTW-related symbols from MKL are loaded into the global namespace, so when `liblal.so` is loaded it uses the MKL symbols instead of the FFTW symbols, and things fall over.
The solution is to somehow force `liblal.so` to use the symbols from the library against which it is linked, and the attached patch is the most generic and least intrusive way I have come up with so far.
Closes #300, closes #478.
### API Changes and Justification
#### Backwards Compatible Changes
- [ ] This change does not modify any class/function/struct/type definitions
in a public C header file or any Python class/function definitions
- [ ] This change adds new classes/functions/structs/types
to a public C header file or Python module
#### Backwards Incompatible Changes
- [ ] This change modifies an existing class/function/struct/type definition
in a public C header file or Python module
- [ ] This change removes an existing class/function/struct/type
from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please
provide a justification why this change is necessary and why it needs
to be done in a backwards incompatible way.
#### Review Status
Please provide details on any reviews related to this change and
and the associated reviewers.https://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2165Adding updated LIGO-India (Aundha) coordinates into LAL2023-06-23T10:19:17ZAditya Vijaykumaraditya.vijaykumar@ligo.orgAdding updated LIGO-India (Aundha) coordinates into LAL### Description
Now that the LIGO-India (Aundha) project is approved and the [coordinates are public](https://dcc.ligo.org/LIGO-T2000158), I wanted to implement these in LAL.
### API Changes and Justification
#### Backwards Compatible...### Description
Now that the LIGO-India (Aundha) project is approved and the [coordinates are public](https://dcc.ligo.org/LIGO-T2000158), I wanted to implement these in LAL.
### API Changes and Justification
#### Backwards Compatible Changes
- [ ] This change does not modify any class/function/struct/type definitions
in a public C header file or any Python class/function definitions
- [x] This change adds new classes/functions/structs/types
to a public C header file or Python module
#### Backwards Incompatible Changes
- [x] This change modifies an existing class/function/struct/type definition
in a public C header file or Python module
- [ ] This change removes an existing class/function/struct/type
from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please
provide a justification why this change is necessary and why it needs
to be done in a backwards incompatible way.
- Currently, LIGO India (old coordinates) are implemented in LAL as I1, whereas the new name is supposed to be A1. However A1 is already in use for the (defunct, AFAIK) ALLEGRO detector, and hence there is duplication. What would be the right thing to do in this case? Should I assign a different name to ALLEGRO, or do away with it altogether, or something else entirely?
#### Review Status
Please provide details on any reviews related to this change and
and the associated reviewers.https://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2067Draft: Use Sphinx to render LALSuite documentation2023-04-17T15:43:34ZDuncan Macleodduncan.macleod@ligo.orgDraft: Use Sphinx to render LALSuite documentation### Description
This MR implements #618+.
### API Changes and Justification
#### Backwards Compatible Changes
- [x] This change does not modify any class/function/struct/type definitions
in a public C header file or any Python ...### Description
This MR implements #618+.
### API Changes and Justification
#### Backwards Compatible Changes
- [x] This change does not modify any class/function/struct/type definitions
in a public C header file or any Python class/function definitions
- [ ] This change adds new classes/functions/structs/types
to a public C header file or Python module
#### Backwards Incompatible Changes
- [ ] This change modifies an existing class/function/struct/type definition
in a public C header file or Python module
- [ ] This change removes an existing class/function/struct/type
from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please
provide a justification why this change is necessary and why it needs
to be done in a backwards incompatible way.
#### Review Status
Please provide details on any reviews related to this change and
and the associated reviewers.Duncan Macleodduncan.macleod@ligo.orgDuncan Macleodduncan.macleod@ligo.orghttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2048added routines to read new cbc injection files2024-01-29T21:35:54ZJolien Creightonadded routines to read new cbc injection files### Description
This adds new routines for reading and handling the new O4 CBC injection files:
https://git.ligo.org/waveforms/o4-injection-file
### API Changes and Justification
#### Backwards Compatible Changes
- [ ] This change do...### Description
This adds new routines for reading and handling the new O4 CBC injection files:
https://git.ligo.org/waveforms/o4-injection-file
### API Changes and Justification
#### Backwards Compatible Changes
- [ ] This change does not modify any class/function/struct/type definitions
in a public C header file or any Python class/function definitions
- [X] This change adds new classes/functions/structs/types
to a public C header file or Python module
#### Backwards Incompatible Changes
- [ ] This change modifies an existing class/function/struct/type definition
in a public C header file or Python module
- [ ] This change removes an existing class/function/struct/type
from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please
provide a justification why this change is necessary and why it needs
to be done in a backwards incompatible way.
#### Review Status
Tom Dent should review.https://git.ligo.org/lscsoft/lalsuite/-/merge_requests/1282Rewrite trigger interpolation to fix numerous bugs and improve unit test cove...2023-04-14T00:11:30ZLeo P. SingerRewrite trigger interpolation to fix numerous bugs and improve unit test coverage### Description
Numerical convergence testing revealed several serious bugs in `TriggerInterpolation.{h,c}` as well as a fundamental unsuitability of the Lanczos and real/imaginary part cubic spline interpolation schemes. This code is u...### Description
Numerical convergence testing revealed several serious bugs in `TriggerInterpolation.{h,c}` as well as a fundamental unsuitability of the Lanczos and real/imaginary part cubic spline interpolation schemes. This code is used by gstlal and affects localization results for offline runs but not online runs; gstlal online runs provide SNR time series to BAYESTAR and so the trigger times are ignored.
This is a rewrite to fix those bugs, improve test coverage, eliminate unnecessary heap allocations, and add one more interpolation algorithm.
Bugs fixed:
* Lanczos kernel was not zeroed outside of filter window.
* Handle corner cases of polynomials with leading zero coefficients. The polynomial that is solved in the cubic spline interplant is generally a quintic, but in degenerate cases may be of any order. Unfortunately, `gsl_poly_complex_solve` does not automatically remove leading zero coefficients. Since we are taking care of these special cases, also dispatch to `gsl_poly_solve_cubic` and `gsl_poly_solve_quadratic` when appropriate.
* Fix corruption of design matrix passed to `gsl_multifit_linear` due to improper casting of unsigned integer values.
* Fix a typo in the quadratic fit implementation that resulted in invalid data being used for the fit.
The added interpolation algorithm does cubic spline interpolation of the amplitude and phase separately (`CubicSplineAmpPhase`). This method exhibits less ripple in the amplitude than the Lanczos algorithm or cubic spline interpolation of the real and imaginary parts. (See, for example, lscsoft/ligo.skymap!155.) This new algorithm will likely be what I recommend that search pipelines use.
In addition to bug fixes and the new interpolation algorithm, I did some refactoring to improve code reuse and make better use of C99 syntax.
Also, I noticed that most of the heap allocations were pretty small. My taste has evolved since I first wrote this code, and I decided to move all of the allocations onto the stack using C99 variable-length arrays where necessary. This should make the code a bit more performant. It will also be a bit easier for client, since it will no longer require setup/teardown calls to allocate workspaces.
Along with the elimination of the setup/teardown calls, I am providing a new API. Previously, usage required three calls (example for the CubicSpline algorithm):
```c
/* these symbols defined elsewhere */
unsigned int window;
double tmax;
double complex ymax;
const double complex *y;
CubicSplineTriggerInterpolant *interp = XLALCreateCubicSplineTriggerInterpolant(window);
XLALCOMPLEX16ApplyCubicSplineTriggerInterpolant(interp, &tmax, &ymax, y);
XLALDestroyCubicSplineTriggerInterpolant(interp);
```
These are still supported, but the new API consists of just one call:
```c
XLALTriggerInterpolateCubicSpline(&tmax, &ymax, y, window);
```
The old API is still available in `TriggerInterpolation.h`, but will issue GCC deprecation warnings if used. The new API is available from `TriggerInterpolate.h`.
### API Changes and Justification
#### Backwards Compatible Changes
- [ ] This change introduces no API changes
- [X] This change adds new API calls
#### Backwards Incompatible Changes
- [ ] This change modifies an existing API
- [ ] This change removes an existing API
If any of the Backwards Incompatible check boxes are ticked please
provide a justification why this change is necessary and why it needs
to be done in a backwards incompatible way.
#### Review Status
This will be part of the BAYESTAR review. CC @zoheyr-doctor, @rosa.poggiani, @surabhi.sachdev.