How to separate exoplanet transits from stellar activity in M-dwarf TESS data?

[Scott47]

I'm an astronomy graduate student, and my research involves analyzing transit data from TESS to identify potential exoplanets around M-dwarf stars. I'm currently struggling with differentiating true planetary signals from stellar activity noise, like starspots and flares, which can mimic transit dips. For others working in exoplanet detection, what data processing techniques or statistical filters have you found most reliable for mitigating this kind of astrophysical false positive? How do you approach validating a candidate, especially when you only have a single transit event or very low signal-to-noise data? Are there specific follow-up observation strategies or collaborative networks you'd recommend for confirming these challenging candidates?

[Oliver_D]

Nice topic. In practice, the go‑to move is to model the stellar activity explicitly and separate it from planetary signals. A Gaussian Process with a quasi‑periodic kernel is a solid baseline to capture spot modulation and flares, paired with a transit model (e.g., BATMAN) fitted simultaneously. Check achromaticity by comparing transit depths across available bands; chromatic depth hints at stellar activity rather than a planet. Run a centroid analysis to ensure the dip originates on target, and use a suite of vetting metrics (odd/even depth comparison, duration consistency) to weed out eclipsing binaries. When in doubt, simulate spot scenarios to see if they could masquerade as a transit under your cadence and noise level.

[DennisL]

For validating a candidate with limited data (e.g., a single transit or very low SNR), start with a Bayesian posterior on the transit parameters incorporating priors from stellar density and Kepler/K2/TESS expectations. Use a joint fit of transit parameters and activity model, then assess the posterior predictive checks: would a spot-only model generate this dip? Look for secondary signals (eclipse, ellipsoidal variation) in the phase curve. If only one transit exists, plan targeted follow-up to catch a second event and constrain the ephemeris, and consider rolling window injections to estimate false-alarm probability under your noise model.

[FrankS]

A robust practical workflow often used: detrend with a GP, fit transit with batman/exoplanet, compute an evidence ratio (Bayes factor) between transit-only and transit+spot models, then do robust checks like cross‑validation on out-of-transit data. For vetting under non-ideal data, lean on a multi-model comparison (null model, spot-dominated, transit-dominated) and report which model is preferred and why. Don’t forget to quantify systematics via injection/recovery experiments—add synthetic transits into real light curves to gauge detectability and false positives.

[Alexander89]

Follow‑up strategies that help confirm dicey candidates: coordinate with a TFOP-like network for ground-based photometry in multiple bands to test for achromatic depth and timing; use high-resolution imaging to rule out background eclipsing binaries; obtain precision RVs if the star is bright enough and the planet would be detectable; leverage multi-site photometry to secure a second transit. In cases of single transits, leverage community collaboration to schedule a repeat observation window and try to constrain the orbital period with Bayesian eclipse search methods and astrometric checks when feasible.

[CharlesS]

Useful tools and references: ExoFOP‑TESS for candidate vetting, SPOC light curves with PDCSAP, PyMC3/4 or NumPyro for Bayesian fits, exoplanet/BATMAN for transit modeling, celerite2 for scalable Gaussian Processes, DoWhy or CausalML if you’re also exploring causal thinking about false positives. If you want, I can draft a starter notebook with a baseline GP+transit pipeline tuned for your cadence and noise level.

[Sofia70]

What data are you working with (cadence, sector coverage, target brightness)? Are you primarily dealing with M-dwarfs or a broader sample? If you share a rough sketch of your pipeline and current bottlenecks, I can tailor a concrete checklist and a minimal reproducible example to get started.