WIP: Added binary script to generate mock data

[sum33it]

Standard information about the request

This is a: new feature and an efficiency update. This PR adds the features to the generation of mock data for third-generation ground-based detectors (@sum33it ) and LISA (@WuShichao). We make use of already existing functions and create a top-level binary file pycbc_generate_mock_data which shall contain i) noise channel, ii) signal channel, and iii) glitch channel separately and together.

This change affects: the offline search, the live search, inference, PyGRB

This change changes: None. Since most of the code is addition to the current codes, it does not change previous codes.

This change: has appropriate unit tests, follows style guidelines (See e.g. PEP8), has been proposed using the contribution guidelines

This change will: not break current functionality, does not require additional dependencies, do require a new release.

Motivation

The mock data generation for next-generation detectors (or for the current generation) for testing PE/search pipelines is an important tool. Even though there are publicly available mock data challenges, the developers might need to generate mock data with their own choice of noise, signal, and even glitches. This PR aims to provide these tools for PyCBC users.

Contents

This PR contains a top-level binary code for generating mock data for a network of ground-based detectors, LISA detector, and example script to generate the mock data.

Links to any issues or associated PRs

None

Testing performed

The example scripts for tests are to be put in examples/mdc_generation. We plan to do tests of mock data generation for a few hours with a chosen binary population and glitch distribution.

Additional notes

• The author of this pull request confirms they will adhere to the code of conduct

[ahnitz]

@sum33it @WuShichao Can you explain why you wouldn't just use pycbc_condition_strain directly? What does this do that it doesn't? And if there is something, why not improve that script? I think some explanation of the use case is needed here. A

[ahnitz]

This should be fixed

[sum33it]

Sure! Fixing it in the next commit.

[sum33it]

@ahnitz There are some reasons to create a top level script:

• We wanted to write a top level script which can be integrated with future planned class for i) glitch generation, ii) signal generation with various option (earth rotation on/off).
• At this moment, pycbc_condition_strain doesn't support multiple IFO option. Although it can be worked on, we thought that addressing it at this top-level script is better option.
• Also, in the long term, we thought that we will package all- a default population (GWTC-4), expected glitch distribution- in a single binary file to generate mock data.

If you still have strong opinion on modifying pycbc_condition_strain only, we can consider that option as well.

[ahnitz]

@sum33it Shouldn't glitch generation be a generic injection capability though? Hence it would automatically work with say pycbc_condition_strain as specified in an injection file?

The same for options for earth rotation, etc. Those should be fundamental capabilities, not high level ones. Also, that is somewhat an option already in the injection configuration, though only as a static parameter that applies to all the injections.

[ahnitz]

@sum33it The other points make more sense assuming you want to have some of the population builtin (maybe some default config file defining the populations??).

[sum33it]

@ahnitz regarding glitch: yes it can be a in a generic injection capability.

Regarding population: Yes I plan to put a default config file and if someone choses default population, this binary script first create a population injection file and then feed it to the pycbc_condition_strain like the script does it now. We can also put few variation of the default population e.g. at higher redshift.

Lastly, I wanted to add an option for the people who just wanted to generate frame file with one injection in a detector network with/without some generic glitch/overlapping signals. These requirements came out from discussion within ET collaboration for the groups which are testing their pipelines and want to generate quick mock data and need a tool for this. So I want to package all these generic options in a single top level script.

[ahnitz]

@sum33it Ok, that makes sense.

[ahnitz]

@sum33it I'd suggest having a proper documentation page within this PR. This is a case, where I think it is more helpful to have then to wait for a later PR.

[sum33it]

@ahnitz I think this is a good idea. I will start the documentation within this PR in parallel. Postponing the documentation for a later PR might lead to procrastination.

[ahnitz]

@sum33it I think the documentation should just be in this PR if that's what you mean.

[WuShichao]

@sum33it Shouldn't glitch generation be a generic injection capability though? Hence it would automatically work with say pycbc_condition_strain as specified in an injection file?

The same for options for earth rotation, etc. Those should be fundamental capabilities, not high level ones. Also, that is somewhat an option already in the injection configuration, though only as a static parameter that applies to all the injections.

We will also make this compitable with LISA Glitch package https://lisa-simulation.pages.in2p3.fr/glitch/