Transit Timing Variations — Reverse N-Body Problem

The Core Idea

When a transiting exoplanet is gravitationally perturbed by a second (unseen) planet, its transit times deviate from a perfect period. These deviations — Transit Timing Variations (TTVs) — encode the perturber's mass, period, and eccentricity. [Source: Holman & Murray (2005), Science 307, 1288 — first TTV prediction/detection; Agol et al. (2005), MNRAS 359, 567]

The reverse n-body problem: given the observed timing residuals, infer the perturber's orbital parameters.

Why This Matters for OpenAstro

Most amateur networks stop at measuring transit times. OpenAstro's pipeline would go further — running the full inverse inference and producing not just timing data but inferred planet parameters. That's a step above existing citizen science astronomy projects and a genuine scientific contribution.

[NOVEL] The framing of OpenAstro as an end-to-end TTV inference platform (not just a data collector) — running Bayesian n-body inversion and publishing posterior distributions on hidden planet parameters — is original to OpenAstro.

The Math

Forward problem (easy): Given masses M₁, M₂ and orbital parameters → simulate expected transit times. Fast, deterministic, used to generate model predictions.

Inverse problem (hard): Given N observed transit times with errors → infer {M₂, P₂, e₂, ω₂} for the perturber. Approached via: - MCMC (Markov Chain Monte Carlo) — explores the posterior over perturber parameter space - Nested sampling (MultiNest, dynesty) — better for multimodal posteriors - TTVFast (Deck et al. 2014) — fast symplectic integrator, designed for TTV likelihood calculations

Estimating n (How Many Bodies to Fit)

Starting assumption is n=2 (transiting planet + one hidden perturber). But: - Multiple perturbers produce superposed TTV signals - Bayesian model comparison (BIC, AIC, or Bayes factors) selects the right n - In practice: fit n=2 first, check residuals, add n=3 only if residuals show structure

The question of "what is the right n" is genuinely open for most systems — this is part of the science.

Useful Existing Tools

Tool	Purpose
TTVFast (Python wrapper: ttvfast-python)	Fast TTV forward model for likelihood evaluation [Source: Deck et al. (2014), ApJ 787, 132]
allesfitter	Full transit + TTV fitting framework [Source: Günther & Daylan (2021), ApJS 254, 13]
juliet	Bayesian transit + RV fitting, handles TTVs [Source: Espinoza et al. (2019), MNRAS 490, 2262]
emcee	Pure Python MCMC sampler [Source: Foreman-Mackey et al. (2013), PASP 125, 306]
dynesty	Nested sampling for multimodal posteriors [Source: Speagle (2020), MNRAS 493, 3132]

Why Distributed Compute Matters Here

MCMC over TTV parameter space is computationally expensive — millions of likelihood evaluations, each requiring an n-body integration. [Source: Deck et al. (2014), ApJ 787, 132 — TTVFast integrator, ~0.5–2 ms per call] This is the natural use case for: - BOINC volunteer compute (from dump.md) - Batch cloud compute on per-campaign basis

The data collection is the bottleneck for most science cases. For TTV inference, computation is the bottleneck. OpenAstro can solve both.

[NOVEL] The strategy of using BOINC parallel-tempering chains as work units — each temperature level dispatched as an independent BOINC job, with the server-side PT swap step run after all chains return — is an original adaptation of parallel tempering to the BOINC volunteer compute model. No existing TTV project does this.

Connection to OpenAstro Pipeline

1. Stage 1: Run TTV inference on archival ETD/AAVSO transit times → validate pipeline against known systems
2. Stage 2: Live transit timing from volunteer network → ongoing inference → discover new perturbers
3. Science output: For each monitored system, maintain a live posterior on perturber parameters

[NOVEL] Maintaining a live, continuously-updated posterior on perturber parameters — rather than a static published result — as the primary science output of the monitoring programme is original to OpenAstro. No existing citizen-science project does live Bayesian inference of this form.

Open Questions

• Which exoplanet system to target first for proof of concept?
• What baseline length of transit timing data is needed before inference is meaningful?
• Can the inference be made robust to heterogeneous data quality across instruments?
• What's the computational budget per system? (determines whether BOINC is needed at Stage 1 or only later)