# Explore MERIDIAN

MERIDIAN is a browser workspace for exploring the recorded gravitational-wave event GW150914. Your experiment is the processing choice: keep the input data fixed, change a filter, and find out which features remain. Each completed analysis produces a reproducible report.

No account, wallet, API key, or Python installation is needed to use the supplied website. Start its local server with `npm start` after installing a supported Node.js version. See README.md for source builds and independent scientific checks.

## Your first experiment

1. Open the workspace. It checks the bundled H1 and L1 data hashes and calculates a run. A returning browser resumes its latest supported saved run; a settings link takes precedence.
2. Inspect **Signal replay**. H1 is Hanford and L1 is Livingston. The displayed processed traces are normalized against each detector's background noise. Use **Align traces using measured lag** to compare their shapes; negative correlation also reverses the displayed L1 orientation.
3. Select **Compare with 50–250 Hz**. The workspace calculates a second band and places the same detector from both runs on identical axes. If the completed run is already the core band, the action offers **Compare with 35–350 Hz** instead.
4. Compare the waveform, signed correlation, relative time lag, and window/background RMS ratios. The data did not change: the filter did. A larger correlation or RMS ratio is not a detection-significance score.
5. Download the JSON under **Analysis receipt**. Choose that file in **Verify a report**, then select **Reproduce this report**. The content hash and signature checks are separate from actually rerunning the calculation.

On a narrow screen, **Analysis settings** opens the controls. All scientific tabs and the first comparison action remain visible. Errors and storage warnings appear beside the active workspace.

## Three useful experiments

### Which features survive the filter?

Compare the broad 35–350 Hz band with the core 50–250 Hz band. Then try 80–300 Hz. Change one setting at a time. Look for stable timing and changing waveform detail, rather than trying to maximize a number.

### What does whitening change?

Keep the band fixed, turn **Whiten with off-source noise** off, and run again. Choose the previous whitened run as the comparison baseline. Whitening changes the frequency weighting; each processed trace is still normalized by its own off-source RMS.

### Can someone reproduce your calculation?

Download a JSON report and import it into another instance containing the same inputs and engine. First check its fingerprint, then reproduce it. An exact match has the same digest. A supported floating-point tolerance match is reported separately and preserves the original report. Altering a committed field without recomputing the digest is rejected; recomputing the digest alone does not make an altered calculation reproducible.

## Controls and views

| Control or view | What it does |
| --- | --- |
| Frequency edges | Choose a band within 20–800 Hz, with at least 20 Hz between its edges. |
| Whiten | Weight the signal using an off-source estimate of noise power. |
| Suppress 60 / 120 / 180 Hz | Apply the documented narrow line-suppression filters. |
| Run analysis | Apply pending settings and create a new completed result. |
| Discard pending changes | Return the controls to the current completed report's settings. |
| Raw strain | Inspect the original calibrated detector samples. |
| Time–frequency | Inspect short-time Fourier power from the processed H1 signal. |
| Inter-detector lag | Inspect the signed correlation across the allowed time shifts. |
| Listen | Hear the processed detector signal. Half speed changes duration and pitch; audio settings never change the report. |
| Compare runs | Overlay one detector from two processing choices on the same axes. |
| Evidence | Inspect provenance, input hashes, implementation checks, and original sources. |
| Mass & distance / Sky localization | Inspect published GWTC-1 reference products. They are not recalculated when you change the filter. |

Pending settings do not update the current plot or report. The interface labels exports as the last completed result and pauses new wallet actions until you apply or discard those changes.

## Keep and move your work

Completed results are saved automatically to this browser's local storage, up to 20 distinct digests. Repeating an existing result retains its existing compatible receipts. When storage is full or unavailable, download the current JSON immediately; a completed calculation is not a guarantee that it was saved.

- **JSON report:** calculation, provenance, fingerprint, and attached receipts for automated verification.
- **Readable report:** self-contained HTML for reading or printing; keep JSON for reproduction.
- **Back up all runs:** one file containing the local archive. Back up before clearing browser data.
- **Restore backup:** checks every report and signature, reproduces every calculation, and writes the merged archive once. A failed check or insufficient capacity leaves the archive unchanged.
- **Copy settings link:** shares processing settings, not a report or receipt. A localhost link only works on the same computer. Hosted links still require access to that site's configured audience.

The archive keeps one primary signature and one primary chain reference for each digest. Existing receipts take precedence when another signer supplies the same report. Keep the incoming JSON when you need its other receipt.

## Optional wallet and chain receipts

On desktop Chrome, enable the OKX Wallet or MetaMask extension, then choose it under **Wallet extension**. If several extensions are detected, explicitly choose one before signing or recording. The selected extension handles the entire operation. Wallet detection never requests account access; access is requested only after you click a receipt action. Extension names are supplied by the extensions themselves.

You can finish every analysis and reproduction step without a wallet. A wallet signature adds an EIP-191 statement about a report digest. It does not send a transaction.

Recording a digest on Base Sepolia or Base is a separate wallet-approved, zero-value self-transaction. Network gas still applies; Base uses real ETH. Only injected EVM wallets and plain accounts without executable or delegated code are supported by this path. The interface defaults to Base Sepolia.

After submission, **Check chain inclusion** verifies the transaction, its contents, its successful receipt, and its position in the canonical block returned by the configured RPC. Submission is not inclusion, inclusion is not finality, and neither proves scientific correctness.

If the receipt is missing, use **Recover an existing transaction** with its network and transaction hash. This performs a read-only verification and does not connect a wallet or send another transaction.

If a transaction failed or was cancelled, **Replace a transaction reference** lets you download a receipt backup, acknowledge the consequence, and remove the local reference. It retains the report and signature. Removing a reference does not cancel a pending transaction. Check the original transaction first to avoid accidentally paying for two submissions. RPC failure alone never removes a receipt automatically.

## What this workspace can establish

It can check input integrity, apply a documented processing recipe, compare configurations, reproduce reports, recover signatures, and inspect chain commitments. It does not search for new events, calculate detection significance, run fresh Bayesian parameter estimation, or reconstruct a new sky map. Only GW150914 is configured. See METHOD.md for the exact recipe and interpretation limits.