lalsuite merge requestshttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests2024-01-18T19:36:04Zhttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2237lal/lib/fft/RealFFT: remove \section and \subsection to make doxygen 1.10.0 h...2024-01-18T19:36:04ZDavid Keiteldavid.keitel@ligo.orglal/lib/fft/RealFFT: remove \section and \subsection to make doxygen 1.10.0 happy### Description
Partially addresses #729. Doxygen 1.10.0 doesn't seem to like mixed use of `##`/`###` on the one hand and `\section`/`\subsection` on the other hand, like RealFFT.[c/h] do it. This patch, simply changing to all-hashes, s...### Description
Partially addresses #729. Doxygen 1.10.0 doesn't seem to like mixed use of `##`/`###` on the one hand and `\section`/`\subsection` on the other hand, like RealFFT.[c/h] do it. This patch, simply changing to all-hashes, seems to work - one loses the anchors defined in the tex-like syntax, but I couldn't find them linked to from anywhere, so I guess it's ok. On the other hand, I couldn't find any note explicitly deprecating the tex-like use, so if there's a more elegant solution @karl-wette feel free to suggest something else.
### 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
---David Keiteldavid.keitel@ligo.orgDavid Keiteldavid.keitel@ligo.orghttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2235Conda envrionment.yml: add tqdm and a note about ligo.lw2024-01-12T16:05:02ZDavid Keiteldavid.keitel@ligo.orgConda envrionment.yml: add tqdm and a note about ligo.lw### Description
as per #726 - edit: also updated the contributing guide
### API Changes and Justification
#### Backwards Compatible Changes
- [x] This change does not modify any class/function/struct/type definitions
in a publi...### Description
as per #726 - edit: also updated the contributing guide
### 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
for @duncanmmacleodhttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2228CONTRIBUTING.md: add instructions on how to run pretty-formatting locally2023-12-07T10:52:42ZKarl WetteCONTRIBUTING.md: add instructions on how to run pretty-formatting locally### Description
Document in `CONTRIBUTING.md` how to run the pretty-formatting build (!2213) locally.
### API Changes and Justification
#### Backwards Compatible Changes
- [x] This change does not modify any class/function/struct/typ...### Description
Document in `CONTRIBUTING.md` how to run the pretty-formatting build (!2213) locally.
### 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.Karl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2213Build system rules for pretty-formatting C and Python code2023-12-07T05:30:52ZKarl WetteBuild system rules for pretty-formatting C and Python code### Description
This MR adds build system rules for pretty-formatting C and Python code. _No code is reformatted by default. Pretty-formatting is entirely opt-in, either on a per-file, per-directory, or per-LALSuite library basis._
Pre...### Description
This MR adds build system rules for pretty-formatting C and Python code. _No code is reformatted by default. Pretty-formatting is entirely opt-in, either on a per-file, per-directory, or per-LALSuite library basis._
Pretty-formatting only works in a Git checkout, and only processes files that have already been committed to Git. Hopefully that will mean that a user can always roll back to an un-pretty-formatted version of the code, in case the pretty-formatting causes problems during development.
C code is pretty-formatted using [Artistic Style](https://astyle.sourceforge.net/). This is a more modern C/C++ formatter than `indent`. I've often used it to tidy up my own code, and it seems reliable. It's available for [RPMs](http://rpmfind.net/linux/rpm2html/search.php?query=astyle), [Debian](https://packages.debian.org/search?keywords=astyle), [Ubuntu](https://packages.ubuntu.com/search?keywords=astyle), [Homebrew](https://formulae.brew.sh/formula/astyle), [MacPorts](https://ports.macports.org/port/astyle/), etc. It supports lots of different options for formatting C/C++ in different styles.
* Artistic Style options are given either in
* A per source config file, e.g. `lalpulsar/lib/.LatticeTiling.pretty.astylerc` will apply to `lalpulsar/lib/LatticeTiling.[ch]`
* A per directory config file, e.g. `lalpulsar/bin/Weave/.pretty.astylerc` will apply to everything in `lalpulsar/bin/Weave/`
* A library top-level config file, e.g. `lalpulsar/.pretty.astylerc`, will apply to everything in LALPulsar
Python code is pretty-formatted using [Black](https://black.readthedocs.io/en/stable/).
* Black is enabled either
* Per file, e.g. the presence of a file `lalpulsar/python/lalpulsar/.simulateCW.pretty.black` will reformat `lalpulsar/python/lalpulsar/simulateCW.py`
* Per directory, e.g. the presence of a file `lalpulsar/python/lalpulsar/.pretty.black` will reformat everything in `lalpulsar/python/lalpulsar`
* Per library, e.g. the presence of a file `lalpulsar/.pretty.black` will reformat everything in LALPulsar
Pretty-formatting is performed by running `make pretty`. A new CI job `lint:pretty` runs `make pretty` to check that code has been pretty-formatted before merging.
### 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.Karl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2222rebrand as LVK Algorithm Library2023-11-21T17:19:07ZAdam Mercerrebrand as LVK Algorithm Library### Description
Rebrands as the LVK Algorithm Library, see #637 for details.
### API Changes and Justification
#### Backwards Compatible Changes
- [x] This change does not modify any class/function/struct/type definitions
in a ...### Description
Rebrands as the LVK Algorithm Library, see #637 for details.
### 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.Adam MercerAdam Mercerhttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2186remove koji builds from CI2023-08-03T04:14:56ZAdam Mercerremove koji builds from CI### Description
Currently the CI only builds SL7 RPMs in Koji as part of the nightly pipeline, SL7 is in the process of being retired and it's making less and less sense to test on this platform. This removes the SL7 Koji builds from CI...### Description
Currently the CI only builds SL7 RPMs in Koji as part of the nightly pipeline, SL7 is in the process of being retired and it's making less and less sense to test on this platform. This removes the SL7 Koji builds from CI.
### 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.Adam MercerAdam Mercerhttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2122Add IMRPhenomXO4a2023-04-24T18:53:11ZJonathan ThompsonAdd IMRPhenomXO4a### Description
Creating the draft merge request to add the IMRPhenomXO4a model currently undergoing review here: [https://git.ligo.org/waveforms/reviews/imrphenomxo4](https://git.ligo.org/waveforms/reviews/imrphenomxo4)
### API Change...### Description
Creating the draft merge request to add the IMRPhenomXO4a model currently undergoing review here: [https://git.ligo.org/waveforms/reviews/imrphenomxo4](https://git.ligo.org/waveforms/reviews/imrphenomxo4)
### 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
- [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
Review completed. For details, see [https://git.ligo.org/waveforms/reviews/imrphenomxo4](https://git.ligo.org/waveforms/reviews/imrphenomxo4)https://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2126More Doxygen improvements2023-04-05T11:18:35ZKarl WetteMore Doxygen improvements### Description
1. Because Doxygen's parsing of (GitLab-flavoured) Markdown isn't great, use an external program (e.g. `pandoc`, `markdown`) to convert Markdown to HTML which is then directly included in the Doxygen docs. If a converter...### Description
1. Because Doxygen's parsing of (GitLab-flavoured) Markdown isn't great, use an external program (e.g. `pandoc`, `markdown`) to convert Markdown to HTML which is then directly included in the Doxygen docs. If a converter can't be found, Markdown is just included as verbatim text, so people can still build the documentation (e.g. to check for errors) without having to install another dependency. Because (GitLab-flavoured) Markdown is now never parsed by Doxygen, this will avoid silly errors like ba513ec4498249d0291ccec418595f7709c614f9 in future. Of course for the online documentation `pandoc` will need to be installed into the relevant containers.
2. Scrape `.gitlab/CODEOWNERS` to get the maintainers for each package, as well as the general LALSuite maintainers. Add these names to the Authors page (now Authors/Maintainers).
3. ~~Change the colour for unvisited hyperlinks so that they stand out more.~~
4. Some minor author list cleanups
### 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.Karl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2031Use static AUTHORS files; add lint job to check mailmap and AUTHORS files2023-04-04T04:51:44ZKarl WetteUse static AUTHORS files; add lint job to check mailmap and AUTHORS files### Description
The `lal*/AUTHORS` files are currently built dynamically; starting from the `lal*/.AUTHORS` files (which record names from the pre-Git history, copyright notices, etc.) and updating with names from the more recent Git hi...### Description
The `lal*/AUTHORS` files are currently built dynamically; starting from the `lal*/.AUTHORS` files (which record names from the pre-Git history, copyright notices, etc.) and updating with names from the more recent Git history. This can only happen if the full repository is available, however, and this is not the case for the GitLab CI runnners which only check out a limited history. As a result the `lal*/AUTHORS` appear not to be updated, as pointed out in #613.
This MR addresses this by committing the `lal*/AUTHORS` files as part of the Git history, so that they are always available in GitLab CI jobs for building packages, documentation, etc. To ensure the `lal*/AUTHORS` files do not become out of date, a `lint:authors` job is added which:
- checks out the full Git history;
- runs `make update-authors` at the top level; this updates the `.mailmap` file and the `lal*/AUTHORS` files, then checks that they are the same as in the Git history. If names are missing, the job fails and the user is asked to run `make update-authors` themselves and commit the results to the repository.
Closes #613
### 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
#### Review Status
cc @adam-mercer for approval. This will mean at least one CI job will try to download the full LALSuite Git history per merge request. When I've been testing this there appears to be minimal performance impact (the `lint:authors` jobs takes ~5 minutes) but I'm not sure if there are any other performance implications (e.g. disk space).
cc @david-keitel FYIKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2117Doxygen: add navigation tabs to other LALSuite packages to each package docum...2023-03-29T21:53:49ZKarl WetteDoxygen: add navigation tabs to other LALSuite packages to each package documentation### Description
Two improvements to the Doxygen documentation:
1. Adds navigation tabs to other LALSuite packages at the top of each Doxygen documentation HTML page. This replaces the current hacky `iframe` container, which only works ...### Description
Two improvements to the Doxygen documentation:
1. Adds navigation tabs to other LALSuite packages at the top of each Doxygen documentation HTML page. This replaces the current hacky `iframe` container, which only works for the top-level documentation.
2. Add a proper landing page for LALSuite itself. To do this run, run the same Doxygen configuration as for the packages in a top-level `/doxygen` directory. The LALSuite documentation page only contains the top-level `README.md` and `CONTRIBUTING.md`, but also contains the same navigation tabs to other LALSuite packages. The search bar from the LALSuite documentation page will also find symbols in other LALSuite packages. (It was for the latter reason that the current `iframe` container defaults to pointing to LALApps, as the last in the dependency chain. Having a separate documentation page for LALSuite itself is a cleaner solution.) I also moved the _LAL Specification and Style Guide_, and the SWIG tutorial, to the top-level LALSuite documentation, and a more visible/easier location to find these (and other general-purpose documentation) than being buried in the library-level documentation hierarchies.
I also played around with the colour scheme, and ended up settling on a greenish tint (by using (20)15-09-14 as numerical colour values).
A screenshot probably makes the changes clearer, see below. Or you can browse a [documentation build](https://lscsoft.docs.ligo.org/-/lalsuite/-/jobs/2593119/artifacts/html/lalsuite/index.html) here.
![Screenshot_LALSuite_Main_Page](/uploads/e7f5c2dae8e7e5c75039158667f7005e/Screenshot_LALSuite_Main_Page.png)
![Screenshot_LAL_Header_SkyCoordinates.h](/uploads/8b53d41da12215a0931bc6de8d1b60a1/Screenshot_LAL_Header_SkyCoordinates.h.png)
### 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
#### Review Status
n/aKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2108CI: fix .docker:tags builds, add [ci tags] commit message trigger for future ...2023-03-06T15:27:45ZKarl WetteCI: fix .docker:tags builds, add [ci tags] commit message trigger for future testing### Description
The RPM/Debian jobs (i.e. `.rpmbuild` and `.debuild`) need the `.ci-lalsuite-tag-build` so that they're available as prerequisites for `.docker:tags`.
To facilitate future testing of the `lalsuite-v*` tags pipeline with...### Description
The RPM/Debian jobs (i.e. `.rpmbuild` and `.debuild`) need the `.ci-lalsuite-tag-build` so that they're available as prerequisites for `.docker:tags`.
To facilitate future testing of the `lalsuite-v*` tags pipeline without actually creating a tag, add `[ci tags]` to the commit message to run the same pipeline.
(I've now changed the jobs environment variables re. deploy actions. `EXECUTE_DEPLOY_ACTIONS=yes` is now set for the scheduled/tag builds on `lscsoft/lalsuite` which are the only 2 builds which should e.g. deploy documentation, push packages/Docker images, etc. All other pipelines possibilities will not have `EXECUTE_DEPLOY_ACTIONS` set and therefore should be safe to run. For example [this pipeline](https://git.ligo.org/ANU-CGA/lalsuite/-/pipelines/502781) is using `[ci tags]` to run the `docker:tags:*` jobs but shouldn't try to push the tagged containers.)
### 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.Karl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2102Short tutorial on using the Python SWIG interface to LALSuite2023-02-27T01:05:31ZKarl WetteShort tutorial on using the Python SWIG interface to LALSuite### Description
A short tutorial on using the Python SWIG interface to LALSuite; should help people started using LALSuite from Python. It's probably not comprehensive (or comprehensively detailed) but best I can do for now. Others are ...### Description
A short tutorial on using the Python SWIG interface to LALSuite; should help people started using LALSuite from Python. It's probably not comprehensive (or comprehensively detailed) but best I can do for now. Others are encouraged to contribute anything missing with their own MRs.
### 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
cc @adam-mercer @duncanmmacleod for approval
cc @david-keitel @rodrigo.tenorio as potentially interested partiesKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2087Refactor conda recipes2023-02-06T20:19:12ZDuncan Macleodduncan.macleod@ligo.orgRefactor conda recipes### Description
This MR refactors all of the sub-package conda recipes to emulate changes from the upstream `lal*-feedstock` recipes.
### API Changes and Justification
#### Backwards Compatible Changes
- [x] This change does not modi...### Description
This MR refactors all of the sub-package conda recipes to emulate changes from the upstream `lal*-feedstock` recipes.
### 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/2027SFT version 3 implementation2023-01-13T10:27:50ZKarl WetteSFT version 3 implementation### Description
This MR implements version 3 of the SFT specification. The 2 major changes are:
- Version 3 SFTs record the window function applied to the time series data before being Fourier transformed. A limited number of windows ty...### Description
This MR implements version 3 of the SFT specification. The 2 major changes are:
- Version 3 SFTs record the window function applied to the time series data before being Fourier transformed. A limited number of windows typically used for CW analyses are currently supported: rectangular, Hann, Tukey. Any other window is recorded as "unknown". Any window parameter (which must be in [0.0, 1.0]) is recorded as a fixed-point decimal with a resolution of 1/5000 (0.0002). Version 3 is fully backward-compatible with version 2 SFTs, which are treated as SFTs with an unknown window.
- A more prescriptive file & directory naming convention for *public* (i.e. published and distributed) SFTs, which records the observing run number, type of data (e.g. h(t), simulated), a production version number, channel name, and window function. SFTs with these filenames should be globally unique, facilitating replication between clusters. The narrow-band SFT naming scheme, which was informally implemented in `splitSFTs.c`, has also be incorporated into the specification.
Implementation details:
- New functions `XLALParseSFTFilenameIntoSpec()` and `XLALBuildSFTFilenameFromSpec()` parse SFT filenames to/from a new `SFTFilenameSpec` struct which breaks down all the possible information fields in an SFT filename.
- A Python function `public_sft_directory()` is added to determine the specified directory name from a public SFT filename. This function has no LALSuite dependencies and therefore could easily be copied elsewhere to e.g. organise SFTs replicated with rucio.
- The `SFTDescriptor` struct records the window type/parameter of input SFTs.
- The `XLALWriteSFT2...()` functions now require window type/parameter information to write SFTs.
- `lalpulsar_Makefakedata_v[45]` now only require the user to specify the window type/parameter with noise SFTs if the SFTs record the window type as "unknown".
- I have cherry-picked Rodrigo's tests added to `testMakefakedata_v5.sh` to check the `--SFTWindowBeta` parameter is used if/only if the window given in `--SFTWindowType` requires it (cf. !2005).
- `lalpulsar_Makefakedata_v5` support writing SFTs with the public filename specification; `SIM` is used in the filename to indicate simulated data.
- `lalpulsar_splitSFTs` supports processing SFTs with the public filename specification.
- New function `XLALRegisterSpecialCWDetector()` allows custom detectors to be registered for the `[XYZ][0-9]` detector prefixes, which are implementation-defined according to the SFT specification. In particular LISA detectors are no longer hard-coded to the `Z[1-9]` prefix. `XLALGetSiteInfo()` now returns a const-pointer to a `LALDetector` instead of allocating a new one, which therefore doesn't need to be `XLALFree()`d.
Closes #336 #614
### 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
- [x] This change modifies an existing class/function/struct/type definition
in a public C header file or Python module
- [x] This change removes an existing class/function/struct/type
from a public C header file or Python module
The `XLALWriteSFT2...()` functions now require window type/parameter information to write SFTs, and hence require additional arguments. I would actually prefer to break the API here, in order to force downstream packages to think about how the SFTs they are writing might have been windowed, and then supply the appropriate information. I think that's preferable to assuming a backward-compatible default (i.e. the window function is unknown) which would be uninformative at best, or incorrect at worst.
The function `XLALGetSiteInfo()` now returns a const-pointer to a `LALDetector` instead of allocating a new one, which save a memory allocation/free. Adapting downstream packages written in C should be straightforward; see the diff for examples. Python/Octave usage through SWIG should be unaffected.
The functions `XLALOfficialSFTFilename()`, `XLALGetOfficialName4SFT()`, and `XLALGetOfficialName4MergedSFTs()` are removed, having been replaced by `XLALParseSFTFilenameIntoSpec()` and `XLALBuildSFTFilenameFromSpec()`. The arguments supplied to these functions are no longer sufficient to fully record all the possible information fields in an SFT filename, as now given by the `SFTFilenameSpec` struct. As any modification to their arguments would be an API break anyway, it's simpler to just remove them.
`XLALValidateSFTFile()` is renamed to `XLALCheckSFTFileIsValid()`. The existing name shadows the SFTReferenceLibrary function `ValidateSFTFile()` in the SWIG wrappers; both map to `lalpulsar.ValidateSFTFile()`. I've found that it would be useful to access `ValidateSFTFile()` directly, e.g. to recover the exact error code from the validation failure for further processing. This API change will need some care in downstream Python packages:
- Because of the name shadowing, call to `lalpulsar.ValidateSFTFile()` will still work, but will now call `ValidateSFTFile()` instead of the (renamed) `XLALValidateSFTFile()`.
- This will lead to a change in behaviour; while the (renamed) `XLALValidateSFTFile()` raised an exception of failure, `ValidateSFTFile()` just returns an error code but does not raise an exception. So any Python code relying on catching an exception from `lalpulsar.ValidateSFTFile()` will need to be changed to use `lalpulsar.CheckSFTFileIsValid()`
- `lalpulsar.ValidateSFTFile()` will still print error messages on failure, however, so it should be clear that a SFT validation failure has occurred
#### Review Status
In addition to the CI builds I ran `make && cd lalpulsar/ && make check` after every commit in this MR to check for any intermediate breakages.
cc @david-keitel @evan-goetzKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2028lalpulsar_MakeSFTs refactoring2022-12-01T00:04:14ZKarl Wettelalpulsar_MakeSFTs refactoring### Description
**Note**: this MR requires !2027, so until !2027 is merged the diff for this MR will also show changes from !2027.
This MR refactors `lalpulsar_MakeSFTs`. Aim is to:
- Remove deprecated options that are no longer needed...### Description
**Note**: this MR requires !2027, so until !2027 is merged the diff for this MR will also show changes from !2027.
This MR refactors `lalpulsar_MakeSFTs`. Aim is to:
- Remove deprecated options that are no longer needed.
- Upgrade the code (which was primarily written 2005--2007) to use modern XLAL interfaces.
- Implement the new public SFT naming convention using functions from !2007.
- Hopefully simplify the code so that it is easier to understand, maintain, and potentially add new features in future.
Main changes:
- The following options of `lalpulsar_MakeSFTs` (and the equivalent options to `lalpulsar_MakeSFTDag`) are no longer supported:
- `-u, --frame-struct-type`, `-H, --use-hot`: no longer required; the modern XLAL frame reading interface determines the channel type automatically. (I believe this will also allow `lalpulsar_MakeSFTs` to run on Virgo frames, which wasn't the case before.)
- `-i, --ifo`: no longer required; the detector prefix is deduced from the channel name (except that e.g. if the channel name is `L0:...` the detector prefix will be `L1`)
- `-D, --make-gps-dirs`: no longer supported; `lalpulsar_MakeSFTs` now writes all SFTs into the same directory, leaving the organising into a directory structure to other scripts
- `-Z, --make-tmp-file`: this is now the default behaviour; `lalpulsar_MakeSFTs` write each SFT to a file with extension `.sft_TO_BE_VALIDATED`, runs `XLALCheckSFTFileIsValid()` (which call the same code as `lalpulsar_SFTvalidate`) on the result, and if successful renames the SFT to a `.sft` extension
- `-X, --misc-desc`: the public SFT filename specification doesn't support arbitrary comments added to SFT filenames
- `-v, --sft-version`: SFTs are always written with the latest version of the specification (currently 3; !2027)
- `-S, --use-single`: this option would process the SFT time series (filtering, windowing, FFTing) in single precision instead of double precision. It has never been used (AFAICT) for production SFTs. Removing this option greatly simplifies the code (where previously all operations were copy-n-pasted for both single and double precision.)
- `lalpulsar_MakeSFTs` now uses the standard LAL window functions provided by `lal/Window.h` instead of its own implementations. This should allow better consistency with e.g. SFTs produced with MFDv5. The `--window-type` option no longer accepts integer options (`0`, `1`, `2`, `3`) but must take a string window name (`rectangular`, `tukey`, `hann`). Passing the (`0`, `1`, `2`, `3`) window options gives detailed error messages as to how the window options have changed (e.g. that the *Matlab style Tukey window* used previously is not identical to the `lal/Window.h` implementation.
- `lalpulsar_MakeSFTs` now writes SFTs with the public filename convention documentation in the SFT specification. This requires 3 new options (which are also passed through from `lalpulsar_MakeSFTDag`):
- `-O OBSERVING_RUN, --observing-run OBSERVING_RUN`: Observing run data the SFTs are generated from, or (in the case of mock data challenge data) the observing run on which the data is most closely based
- (Note that the `-O` option to `lalpulsar_MakeSFTs` used to specify a log file directory. I've merged that option with `-o`, which also specifies a log file directory, as `lalpulsar_MakeSFTs` is running out of letters for options.)
- `-K {RUN,AUX,SIM,DEV}, --observing-kind {RUN,AUX,SIM,DEV}`: `RUN` for production SFTs of h(t) channels; `AUX` for SFTs of non-h(t) channels; `SIM` for mock data challenge or other simulated data; or `DEV` for development/testing purposes
- `-V OBSERVING_VERSION, --observing-version OBSERVING_VERSION`: Version number starts at 1, and should be incremented once SFTs have been widely distributed across clusters, advertised as being ready for use, etc. For example, if mistakes are found in the initial SFT production run after they have been published, regenerated SFTs should have a version number of at least 2.
- Otherwise, `lalpulsar_MakeSFTs` retains the same options as before, and should generate the same output. This has been confirmed at least by `testMakeSFTs.sh` but may require further testing.
Notes:
- Another benefit of porting to modern XLAL frame reading interface is that `lalpulsar_MakeSFTs` can now handle gaps in the frame data itself, rather than having to be given a set of contiguous frames. This feature currently isn't needed as `lalpulsar_MakeSFTDag` takes care of the gaps, but it could in future be used to simplify the SFT generation pipeline if desired; with `lalpulsar_MakeSFTs` doing the work of handling gaps itself, `lalpulsar_MakeSFTDag` could probably be simplified quite a bit.
- In using the modern XLAL frame reading interface I've turned on checksum validation of input frames using the `LAL_FR_STREAM_CHECKSUM_MODE` mode. I'm not sure whether the old legacy LAL interface enabled the same option. In any case this should definitely address #404.
- As noted above, `lalpulsar_MakeSFTs` now essentially runs `lalpulsar_SFTvalidate` on every SFT before it is renamed to its final filename. This should mean SFT production pipelines are less likely to write corrupted SFTs; if e.g. jobs in the HTCondor DAG crash, any partially-written SFTs will be clearly identifiable as having `.sft_TO_BE_VALIDATED` extensions.
- `MakeSFTs.c` itself is reduced from ~2100 lines to ~500 lines without losing any essential functionality. With various deprecated/debugging code removed, readability is IMHO much approved. So hopefully this should main future maintenance and improvements a lot easier.
#### lalpulsar_CopySFTs
I've also written a new script `lalpulsar_CopySFTs` for copying SFTs between directories. This is similar in spirit to Greg's `CopySFTs.tclsh` script but is a complete rewrite in Python. The script does the following:
- copies SFTs from a source directory (recursing into subdirectories) to a destination directory. The destination directory structure follows the SFT directory naming convention in the SFT specification.
- each SFT is copied to a temporary `.sft_TO_BE_VALIDATED` extension, `ValidateSFTFile()` is run on each file, and finally the SFT moved to its final `.sft. extension
- the script can parallelise SFT copying across multiple processes to speed up copying large numbers of SFTs
I have tested the script works correctly, but I haven't tested its performance on a large number of SFTs as yet.
#### lalpulsar_MakeSFTDag
I've also made a few changes to `lalpulsar_MakeSFTDag`:
- The `writeToDag()` function now takes the user command-line options `args` as a variable, instead of passing in each command-line option individually, which makes it much easier to add/remove options
- I've also updated `writeToDag()` to use modern Python f-strings for constructing the DAG output
- The options `lalpulsar_MakeSFTDag` passes on to `lalpulsar_MakeSFTs` have been synchronised with the new/deprecated options to `lalpulsar_MakeSFTs`
- The `-O` and `-o` options to `lalpulsar_MakeSFTDag`, which both specified log file directories with the same default (`'logs'`) have been conflated into a single `-o` option, as I wanted to re-purpose the `-O` option for the observing run number for the public SFT filename spec.
- The new `-O`, `-K`, and `-V` options for the public SFT filename spec. I've made these mandatory so that there aren't forgotten to be set correctly for h(t) SFT production. For non h(t) usage, e.g. for Fscans I suggest using `-O 100 -K AUX -V 1`, i.e. observing run number not relevant, "auxilliary" non h(t) data, version 1.
### 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
No library API changes, but users of `lalpulsar_MakeSFTDag` (or `lalpulsar_MakeSFTs` if anyone uses that code directly) will need to update their scripts.
#### 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
#### Review Status
In addition to the CI builds I ran `make && cd lalpulsar/bin/MakeData/ && make check` after every commit in this MR to check for any intermediate breakages.
cc @david-keitel @evan-goetz @keith-rilesKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2057fix lalpulsar doxygen header pages2022-11-26T03:37:04ZDavid Keiteldavid.keitel@ligo.orgfix lalpulsar doxygen header pages@karl-wette some things seems to have broken at some point with doxygen rendering. Here's a potential fix to one issue, I'll report others separately.
This one is about some "header" pages being mostly blank, showing just the group info...@karl-wette some things seems to have broken at some point with doxygen rendering. Here's a potential fix to one issue, I'll report others separately.
This one is about some "header" pages being mostly blank, showing just the group info and nothing about function prototypes etc:
* https://lscsoft.docs.ligo.org/lalsuite/lalpulsar/group___fstatistic_tools__h.html
* https://lscsoft.docs.ligo.org/lalsuite/lalpulsar/group___transient_c_w__utils__h.html
* https://lscsoft.docs.ligo.org/lalsuite/lalpulsar/group___sin_cos_l_u_t__h.html
* https://lscsoft.docs.ligo.org/lalsuite/lalpulsar/group___compute_fstat__h.html (shows at least submodules, but missing the rest too)
This seems to be an issue with `// @{` type markup. In the first commit, I started changing that and the group info to `*` (because I just compared to other pages that still look correct, e.g. https://lscsoft.docs.ligo.org/lalsuite/lalpulsar/group___line_robust_stats__h.html and noticed that those used that syntax). But then I found other files that use `///` for the group info and still look fine, so I realised that a minimal `// @{` -> `/// @{` change was already sufficient (example in second commit).
Do you have a preference for the minimal change, or to use the opportunity to standardise on one format?
Also if we want to standardise more, also sometimes the group info block comes before macros and `#include`s, sometimes after. That doesn't have an impact I think, but might help maintenance to standardise too.Karl WetteDavid Keiteldavid.keitel@ligo.orgKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/20003-level CI build system for LALSuite2022-11-07T07:34:31ZKarl Wette3-level CI build system for LALSuite### Description
This MR implements a 3-level CI build system for LALSuite, following #559.
1. Push events trigger a minimal CI pipeline which runs some basic build checks. The idea is that this pipeline will likely be run many times as...### Description
This MR implements a 3-level CI build system for LALSuite, following #559.
1. Push events trigger a minimal CI pipeline which runs some basic build checks. The idea is that this pipeline will likely be run many times as a feature branch is developed, so it should minimize run time and resources. The follows CI jobs are run:
1. A basic package-level build which build LALSuite libraries in sequence from the tarballs. This replaces the RPM/Debian/Conda package builds for push events only, since *at this stage* we only care whether LALSuite builds, not whether the packaging is working.
2. Top-level build
3. Documentation build
4. Lint checks
2. Merge requests trigger the full CI pipeline, which previously ran only as part of the nightly build. The idea is to avoid the perennially tedious situation where changes are merged into LALSuite, after the normal build passes, only for the nightly build to then fail some time later, which then requires people to go back and fix the broken build and/or revert changes (see e.g. !1997, !1999 for 2 recent examples) which wastes valuable person-power. Running the full CI pipeline at merge request time should prevent broken changes being pushed in the first place. (Note the the basic package-level build from the push CI pipeline is *not* build for MRs, as it's essentially redundant with the RPM/Debian/Conda package builds.)
3. The scheduled nightly build now only runs deployment tasks, although some of those (e.g. updating Docker images) do require some build jobs to be re-run. Generally the nightly build should *not* run jobs that were not run during merge commits, to avoid the situation described above from occurring. Currently the only jobs in this category are the Koji build jobs, which should be fine as by this point the normal RPM builds will have passed.
(Perhaps in future, we may want to add a ~weekly pipeline which runs the full CI pipeline to test for upstream breakages, for now though I don't think that is necessary.)
If changes are being made that will (or are suspected will) affect the platform/compiler/packaging jobs, once can use special commit messages to includes those jobs in the push CI pipeline; for example, add `[ci rpm]` to a commit message to run the RPM packaging jobs as part of a normal push. Note that these messages are opposite from the previous `[skip ...]` messages which excluded jobs; these were billed as most useful for skipping the CI for e.g. documentation changes, which are relatively infrequent, and you then had to add a dozen `[skip ...]` messages to skip the entire CI build. I think it's more useful to have codes which include extra jobs into the minimal push pipeline which you might want to test before submitting an MR.
The new CI pipeline setup is documented in `CONTRIBUTING.md`.
I've also tried to minimize the number of jobs with `retry: 1`, to minimize cases where jobs are being rerun due to build failures. At the moment `retry: 1` is only added to
- jobs which AFAICT require external repositories (e.g. `yum`, `apt-get`) which might be down, i.e. the RPM/Debian/Conda, upgrade, platform, coverage tests;
- MacOSX jobs, where from memory the CI runners can be a little more flaky than the Linux ones.
I've also used [`interruptible`](https://docs.gitlab.com/ee/ci/yaml/#interruptible) to denote which jobs can be cancelled when a new pipeline starts, which should also save some cycles. I've currently marked all jobs interruptible apart from MacOSX jobs (due to issues with permission errors;
!1743) and deploy jobs (which only run nightly anyway).
In order to get the full CI build to pass I've allowed the `gcc:12` and `upgrade:debian:bullseye` to fail; once this is merged it should be more straightforward to get those fixed, as the MR CI pipeline won't pass unless they are fixed.
### 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
#### Review Status
Closes #559
cc @adam-mercer @duncanmmacleodKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2036Commits for LALPulsar release request #6202022-11-03T15:17:03ZKarl WetteCommits for LALPulsar release request #620### Description
This MR contains the commits for a backward-compatible LALPulsar release requested in #620. It includes:
- backward-compatible commits from !2009 - needed for !2021
- !2021 - needed by PyFstat
- ~~!1986 - needed for Fsc...### Description
This MR contains the commits for a backward-compatible LALPulsar release requested in #620. It includes:
- backward-compatible commits from !2009 - needed for !2021
- !2021 - needed by PyFstat
- ~~!1986 - needed for Fscan~~ already released in LALPulsar 5.1.0
- !1990 - needed for Fscan
- !1996 - bug fix to simulateCW.py
- !2025 - documentation fixes
Some commits from !2009 didn't apply cleanly and needed to be resolved manually. That said, I've confirmed the final branch is merge-compatible with the current master 82d93aab6dc02ff72e0fa6add28f5ce33cd352ea, i.e. I can merge this branch into master cleanly, and vice versa.
### 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
!2021 adds some new functions.
I ran [ABICC](https://github.com/lvc/abi-compliance-checker) between the last LALSuite release and this branch, which gave [this report](/uploads/6df52a25f2258b1bdb6b6585d79b1d19/compat_report.html). The only issue it highlights is the removal of the function `CheckIfSFDBInScienceMode()`; this function isn't actually removed, but was re-declared `static` in !2009 as it's an internal function. It's never been declared in the public LALPulsar headers, so doesn't qualify as an ABI break.
#### 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
#### Review Status
cc @adam-mercer
cc @david-keitel @evan-goetz Please confirm this contains all the changes you need for PyFstat / Fscans.Karl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/2009Reorganise LALPulsar SFT library code2022-11-03T02:50:53ZKarl WetteReorganise LALPulsar SFT library code### Description
LALPulsar library code for handling SFTs and related objects (timestamps, catalogs, PSDs, etc.) is currently split across 2 source files (shown with line numbers):
```
3615 SFTfileIO.c
3259 SFTutils.c
6874 total
``...### Description
LALPulsar library code for handling SFTs and related objects (timestamps, catalogs, PSDs, etc.) is currently split across 2 source files (shown with line numbers):
```
3615 SFTfileIO.c
3259 SFTutils.c
6874 total
```
with matching headers. Both of these source files have become quite large over the years, and functions for different objects/tasks have got mixed together, which makes both files quite hard to navigate. It's also no longer clear what is the organisational split between "I/O" and "utilities", e.g. `SFTfileIO.c` contains plenty of code which is not directly related to SFT file I/O.
This MR reorganises this code as follows:
- `SFTutils.h` is deprecated, and its contents moved to `SFTfileIO.h`. (LALPulsar will still install `SFTutils.h` but if `#include`d it will raise a `#warning` and then just include `SFTfileIO.h`.)
- The source code in both `SFTfileIO.c` and `SFTutils.c` is reorganised into several new files:
```
92 SFTinternal.h # internal definitions and prototypes shared across all SFT code
537 FindFiles.c # XLALFindFiles()
1056 PSDtypes.c # functions for handling PSDs and noise weights
445 SFDBfileIO.c # XLALReadSFDB()
922 SFTcatalog.c # functions for handling SFT catalogs
1409 SFTfileIO.c # now just contains SFT file I/O code
364 SFTnaming.c # SFT file naming convention and related functions (e.g. looking up detector prefixes)
869 SFTtimestamps.c # functions for handling timestamps
1256 SFTtypes.c # basic functions for creating/destroying/manipulating SFT types, e.g. SFTtype, SFTVector, MultiSFTVector
6950 total
```
- Finally I've used `git blame -C` to try to update the copyright notices for all the new files.
The diffs for this MR probably won't be very helpful given the movement of code. Note that the overall lines of code hasn't changed much (6874 to 6950), which is hopefully a sign I haven't deleted anything important...
Aside from code reorganisation, there are a few other minor clean-ups:
- Removed the long-deprecated `PulsarSourceParams` struct from `PulsarDataTypes.h`; this struct was only used by the `PulsarSignalParams` struct in `GeneratePulsarSignal.h`, so I've just merged the `PulsarSourceParams` struct definition into the `PulsarSignalParams` struct.
- `SFTfileIO.c` uses a function `calc_crc64()` to compute the SFT check-sum; this function was originally copied from the SFT reference library, but since that code is now part of LALPulsar I've removed the `SFTfileIO.c` version of the CRC function and instead pointed `SFTfileIO.c` to the equivalent function in `SFTReferenceLibrary.c`
- `SFTReferenceLibrary.h` declares a function `ReferenceSFTLibraryVersion()`; since this code is no longer a separate package, I've removed this function.
### 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
- [x] This change removes an existing class/function/struct/type
from a public C header file or Python module
Removes deprecated functions/structs in the name of general housekeeping of the LALPulsar API; unlikely to break any downstream packages.
#### Review Status
cc @david-keitelKarl WetteKarl Wettehttps://git.ligo.org/lscsoft/lalsuite/-/merge_requests/1973Resolve "doxygen warning/error: documented empty return type of FFT plan func...2022-10-24T16:26:24ZDavid Keiteldavid.keitel@ligo.orgResolve "doxygen warning/error: documented empty return type of FFT plan functions"### Description
Removes instances of documented None/void returns that newer doxygen versions (tested with 1.9.3 currently on conda-forge) don't seem to like. For comparison, the CI seems to currently run with 1.8.13.
* 4 instances of ...### Description
Removes instances of documented None/void returns that newer doxygen versions (tested with 1.9.3 currently on conda-forge) don't seem to like. For comparison, the CI seems to currently run with 1.8.13.
* 4 instances of `@return None` in lal/lib/fft which should be ok to just remove, matching other destructor functions
* 1 claim of an actual return in lalinference while that function is actually also void. This seems to just seek through a file and indeed not return anything.
* 1 claim of an actual return in `lalpulsar/bin/HeterodyneSearch/ppe_roq.c` while that function is actually also void - @matthew-pitkin for this one it wasn't actually clear to me where the stuff the function calculates ends up, as there is no `[in/out]` argument either; is it just written to a file? Help string could be amended maybe.
* 3 more in `lalpulsar/bin/TwoSpect/` which seem to be leftovers from changing the return type a long time ago and the remaining documentation is clear enough (cc @evan-goetz )
### 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.
Closes #570