I'm an astronomy graduate student designing my thesis project around exoplanet detection, and I'm trying to decide between focusing on refining transit photometry data from space telescopes or developing new algorithms for radial velocity analysis of ground-based observations. My university has access to both types of datasets. For other researchers in the field, what are the current limitations and most promising frontiers for each method? I'm particularly interested in the challenges of mitigating stellar activity noise in radial velocity measurements and the potential for machine learning to identify false positives in transit surveys. What computational resources and software pipelines are considered essential for serious work in either of these areas today?
Transit frontiers and limitations: Space-based transit photometry has amazing precision, but systematics from pointing, thermal drift, and focal-plane changes still dominate for small planets. The current best practice combines pixel-level decorrelation (PLD) with Gaussian Process detrending to separate astrophysical signals from instrument effects. Injection-recovery tests are essential to quantify completeness and biases. For ML-ready vetting, use a mixture of physics-based checks (centroid shifts, odd/even depth, transit duration) and a trained classifier. Recommended pipelines and tools include Lightkurve for data access/pre-processing, batman for light-curve modeling, and exoplanet or PyMC3-based models with celerite for scalable Gaussian Processes. For false positives, adapt the robovetter approach from Kepler/TESS and build cross-checks with Gaia astrometry and centroid motion to reduce contamination.
Radial velocity frontiers: The dominant barrier is stellar activity noise, especially for active or slowly rotating stars. Practical frontiers include multi-wavelength RVs to separate activity from planet signals, and GP-based activity modeling with quasi-periodic kernels that can be tied to photometric or spectroscopic activity indicators (logR′HK, BIS SPAN, FWHM). Multi-output GPs or hierarchical models can borrow strength across activity proxies. Near-IR RVs can help if activity dominates in the optical. For sampling, RadVel and the exoplanet package (with celerite2 for scalable GPs) are robust choices; use emcee or dynesty for robust posterior exploration and run multiple chains with convergence diagnostics. Calibrate with simulated planets injected into real data to evaluate sensitivity and false-alarm rates.
Computational resources and essential pipelines: Transit work benefits from Python tools (Lightkurve, batman, exoplanet) plus a reasonable workstation or cluster for GP-powered detrending and MCMC. Ground-based RV analyses benefit from similar stacks plus robust spectrograph pipelines (RadVel/exoplanet with celerite, plus good time management for large MCMC runs). In both cases, a reproducible workflow is key: Snakemake or Nextflow to orchestrate steps; Docker/conda environments for reproducibility; version control (Git) with a data management plan; and keep a record of data provenance and modeling decisions. For data storage, have a pipeline that can ingest Kepler/K2/TESS, plus your own RV data, and produce standardized outputs (posteriors, detection significance).
Software and workflow tips: use orthogonal validation—photometry plus RV results; use posterior predictive checks to ensure the model can reproduce the data; document model choices and priors. For high-quality publication, consider open notebooks or containerized workflows with DOIs for code and datasets; deposit preprints with links to code artifacts.
A starter plan: if you want, I can draft a two-column comparison sheet (Transit vs RV) with recommended toolkits, typical compute needs, and a starter 6-month plan to get you up to speed in either path. Also, what telescope/spectrograph are you planning to work with? That can tilt the recommended software and data access.