Open Gravitational-Wave Data Products

Open gravitational-wave data are a set of related scientific products, not a single strain file. Reproducing an event claim needs the calibrated time series and the metadata that determines when and how it may be used. Reproducing a population claim additionally needs event selection, sensitivity or injections, per-event likelihood information, and the population assumptions. A product is usable only when its release, schema, units, provenance, and integrity are identifiable.

Helpful background. Gravitational-Wave Astronomy supplies the meanings of strain, calibration, data-quality, posterior, and sensitivity products. Relativistic Cosmology supplies distance, redshift, and reference-frame metadata needed by siren products. Black-Hole Astrophysics supplies the source and host-population quantities carried by event catalogs.

From detector strain to analysis inputs

The measured detector output becomes dimensionless strain only after calibration. Schematically in the frequency domain,

$$\widetilde h(f)=R(f)\,\widetilde e(f),$$

where $\widetilde e$ is an error signal and $R$ is the response model for a specified calibration epoch. Public strain is therefore derived data. Its meaning depends on detector, GPS interval, sample rate, processing branch, calibration release, and usage notes. A value of $h(t)$ without those qualifiers is not a reproducible observation; the public-release structure and format conventions are described by Abbott et al. 2021, §§2–4.

The minimum product set depends on the claim:

Product	Identity that must be frozen	Scientific role
Calibrated strain	Detector, GPS start and duration, sample rate, release and processing branch, channel, units, byte count, checksum	Supplies the analyzed time series; distinguishes, for example, unmodified from noise-subtracted data.
Segment and data-quality state	Dataset version, flag and bit definitions, detector, valid intervals, hardware-injection state	Defines which samples are analyzable and which veto or caveat was applied.
Calibration information	Response release, validity interval, amplitude and phase uncertainty model, correction history	Propagates instrument uncertainty into amplitude, phase, and distance.
Event or catalog record	Catalog and event revision, GPS time, detector network, search/pipeline identity, significance fields and their definitions	Identifies the trigger; a summary table is not an event likelihood.
Sky map or alert product	Notice and map revision, generating pipeline, coordinate convention, FITS schema, file hash	Supports follow-up and association while preserving alert evolution.
Parameter-estimation product	Sample release, waveform, PSD, likelihood settings, priors, calibration treatment, weights and evidence convention	Represents a posterior conditional on a particular analysis, not raw observational truth.
Search-sensitivity product	Search configuration, analyzed live time, injection population, found/missed status, weights, threshold	Normalizes rates and population likelihoods through the actual selection.
External host or counterpart data	Survey/catalog release, footprint and mask, redshift/photometry calibration, completeness, license	Connects the gravitational-wave likelihood to redshift or another messenger.
Software environment	Source revision, dependencies, runtime or container, numerical precision, seed and configuration	Makes transformations and stochastic inference interpretable.

These inputs must describe the same analysis: omit a necessary product and the answer can silently change. A strain-only matched-filter demonstration may need no galaxy catalog, but it still needs detector state and a PSD prescription. A standard-siren population analysis needs every row relevant to both event numerator and selection denominator.

A posterior file is not a likelihood

For model $M$ and parameters $\theta$,

$$p(\theta\mid d,M) =\frac{\mathcal L(d\mid\theta,M)\,\pi(\theta\mid M)}{Z_M}.$$

Posterior samples therefore inherit the waveform, noise treatment, calibration, prior, and sampler. To reuse samples under a population density $\pi_{\rm pop}(\theta\mid\Lambda)$, one typically forms an importance sum containing

$$w_k(\Lambda) \propto \frac{\pi_{\rm pop}(\theta_k\mid\Lambda)} {\pi_{\rm event}(\theta_k)},$$

provided the released samples cover the target support and their weights are handled correctly. Event reweighting does not supply the selection efficiency

$$\alpha(\Lambda) =\int p_{\rm det}(\theta) \pi_{\rm pop}(\theta\mid\Lambda)\,d\theta.$$

That term requires a search-sensitivity model or an injection release. Nor can posterior samples alone reconstruct a Bayesian evidence if the necessary likelihood normalizations and sampling record are absent.

Reading an official release

As of 2026-08-18, the GWOSC public API documentation exposes version-aware event records, strain archives, dataset metadata, and timeline segments. The API is a discovery and metadata interface; a query result should be saved and hashed rather than assumed immutable because its URL still resolves.

The official GW170817 release is a useful bounded example. It identifies a persistent dataset DOI, offers strain in HDF5, Frame, and compressed text formats, separates data before and after noise subtraction, publishes checksums and technical caveats, links sky maps and parameter-estimation samples, records a revision history, and states a CC BY 4.0 license and acknowledgement guidance. Its notes also show why product labels matter: the two processing branches differ in glitch and noise treatment, and their valid analysis bands and intervals are not interchangeable.

Across catalogs, event revisions can alter metadata or preferred analyses. The GWTC-5.0 methods paper describes the searches, event validation, calibration, data-quality tools, parameter estimation, and software used for that catalog LIGO–Virgo–KAGRA 2026, §§2–6. A catalog page or API field is still only a summary of those choices. The release paper, technical notes, data files, and product-specific records remain part of the evidence.

Integrity and semantic validation

A robust acquisition record contains the persistent identifier, release and sub-release, exact URL or object key, retrieval date, byte count, cryptographic hash where available, license, and acknowledgement. Checksums establish byte identity; they do not establish that the correct branch, detector, epoch, or units were chosen.

After acquisition, test semantics before analyzing physics:

1. verify hash, decompression, schema, array type, finite values, detector name, GPS origin, duration, and units;
2. check $N=f_sT$ samples when the release convention implies a uniformly sampled half-open interval;
3. confirm that the requested interval lies inside the declared science and quality segments and interpret every active bit;
4. compare alternate file formats after decoding, allowing only the release-declared text precision rather than demanding byte equality;
5. check a sky map for nonnegative probability and unit normalization in the map’s own pixel convention;
6. inspect posterior weights, prior support, parameter frame, waveform label, and effective sample size;
7. verify that injection weights and found/missed classifications reproduce a documented selection benchmark.

For a strain benchmark, compare spectra and a band-limited inner product while varying file format, sample rate after anti-alias filtering, PSD segment length, window, and analyzed duration. For a probability product, refine sky resolution or posterior/injection sample count and report the stable statistic together with Monte Carlo error. Aggregate agreement can hide a localized failure: a good overall spectrum does not excuse a wrong event-time window, and normalized posterior weights do not prove target-prior support.

The companion GW150914 matched-filter calculation provides an executed example: hash-checked V2 strain, decoded quality and injection masks, a supplied waveform, pinned dependencies, and numerical comparison tolerances. It demonstrates retrieval and one filtering statistic; it does not reproduce parameter estimation or search significance. Network unavailability, a changed remote object, undocumented schema drift, a hash mismatch, missing calibration uncertainty, or unavailable collaboration-only products must be reported as limitations rather than filled with guessed defaults.

Choosing the reproducibility boundary

Four boundaries should not be conflated:

• Artifact reproducibility: the same released bytes can be retrieved and decoded.
• Derived-product reproducibility: documented conditioning reproduces a spectrum, signal-to-noise ratio, sky map, or posterior summary within a declared tolerance.
• Method reproducibility: an independent implementation applied to the same public inputs gives statistically compatible results.
• Production replication: the collaboration’s complete private or distributed production system is recreated.

Open products can support the first three when the release is complete enough. They do not imply the fourth. The practical end-to-end workflow is developed in Reproducing an Event Analysis.

Common pitfalls

Using a mutable URL as the version. A URL locates an object; it need not identify its content forever. Record the release, persistent identifier, retrieval date, and hash.

Treating data-quality zeros as missing data. Bitmasks have release-specific semantics. Decode the definitions before deciding whether a sample is valid, vetoed, or affected by a hardware injection.

Reweighting outside posterior support. Importance weights cannot recover parameter regions absent from the released event posterior. Low effective sample size is a failure diagnostic, not a nuisance to hide by smoothing.

Exercises

1. Detect a length inconsistency. A release describes a uniformly sampled $4096\,\mathrm{s}$ strain interval at $4096\,\mathrm{Hz}$. How many samples should it contain? What does a decoded array with one fewer sample imply?

Solution

For a half-open interval with no duplicated endpoint,

$$N=f_sT=4096\times4096=16{,}777{,}216.$$

An array of length $16{,}777{,}215$ is inconsistent with those metadata. Possible causes include truncation, a decoding error, or a different interval convention. The correct response is to inspect the schema and release notes and verify the file hash—not to pad a zero or silently change the duration.

2. Reweight a distance prior. Event samples were drawn with a luminosity-distance prior $\pi_{\rm old}(D_L)\propto D_L^2$ over a finite interval. A target calculation uses $\pi_{\rm new}(D_L)\propto1$ on the same interval. What distance dependence should the importance weight have, and what additional product is needed for a population rate analysis?

Solution

Within the common support,

$$w(D_L)\propto \frac{\pi_{\rm new}(D_L)}{\pi_{\rm old}(D_L)} \propto D_L^{-2}.$$

The finite bounds and all other prior factors must also match. For a population rate or detected-event likelihood, these event weights are insufficient: one also needs the matching search-sensitivity or injection product to calculate the selection efficiency $\alpha(\Lambda)$.

References

• Abbott, Rich, et al. “Open Data from the First and Second Observing Runs of Advanced LIGO and Advanced Virgo.” SoftwareX 13 (2021): 100658. DOI. Open PDF.
• Gravitational Wave Open Science Center. “Data Release for Event GW170817.” Dataset DOI 10.7935/K5B8566F; revision history through 2019. Accessed August 18, 2026. Release. Dataset DOI.
• Gravitational Wave Open Science Center. “GWOSC Public API Documentation.” Accessed August 18, 2026. Documentation.
• LIGO Scientific Collaboration, Virgo Collaboration, and KAGRA Collaboration. “GWTC-5.0: Methods for Identifying and Characterizing Gravitational-Wave Transients.” arXiv:2605.27224v2 (2026). Preprint. Open PDF.