Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LauraSilRu/exoplanet-profiler/llms.txt

Use this file to discover all available pages before exploring further.

ExoProfiler uses 12 physical variables selected during EDA as the best candidates for capturing orbital, size, thermal, and stellar diversity across the exoplanet population. These variables feed every stage of the pipeline — preprocessing, PCA, and clustering — in a fixed canonical order.

Variable Selection Rationale

Variables were chosen for their scientific relevance to planetary characterization: orbital architecture, planetary bulk properties, thermal conditions, and host-star properties. Several pairs within the 12 are strongly correlated (for example, stellar radius and stellar mass). These were deliberately retained rather than pre-screened, because PCA is specifically designed to summarize redundant dimensions into orthogonal components. Removing correlated variables before PCA would discard information without adding robustness.

Planetary Variables

The seven planetary variables describe each exoplanet’s orbit, physical size, and thermal environment.
VariableDescriptionUnitTransformNull %
pl_orbperOrbital perioddayslog1p0.11%
pl_orbsmaxOrbital semi-major axisAUlog1p22.53%
pl_radePlanetary radiusEarth radiilog1p1.21%
pl_bmassePlanetary massEarth masseslog1p31.76%
pl_orbeccenOrbital eccentricity0–1 (dimensionless)none31.32%
pl_insolInsolation flux (relative to Earth)S⊕log1p57.58%
pl_eqtEquilibrium temperatureKnone26.26%

Stellar Variables

The five stellar variables describe the host star that each exoplanet orbits. They provide context for orbital stability, habitability, and detection conditions.
VariableDescriptionUnitTransformNull %
st_teffStellar effective temperatureKnone2.53%
st_radStellar radiusSolar radiilog1p0.33%
st_massStellar massSolar massesnone13.30%
st_metStellar metallicitydexnone24.51%
st_loggStellar surface gravity (log)log(cm/s²)none (already log-scale)9.56%

Transform Decisions

Before scaling, several variables receive a log1p transformation. The logic behind each decision is as follows:
  • log1p(x) applied to pl_orbper, pl_orbsmax, pl_rade, pl_bmasse, pl_insol, and st_rad — these are positive quantities with heavy right-skewed distributions (e.g., orbital periods span fractions of a day to thousands of days). Compressing their range before scaling prevents extreme values from dominating the PCA solution.
  • pl_orbeccen excluded from log1p because it is bounded between 0 and 1 and does not exhibit the unbounded right tail that motivates the transform.
  • st_logg excluded from log1p because it is already expressed on a logarithmic scale (log cm/s²); applying a second logarithm would distort rather than normalize it.
  • All 12 variables then pass through RobustScaler, which centers on the median and scales by the interquartile range. This makes the pipeline robust to physical outliers such as extreme hot Jupiters without deleting or clipping them.

FEATURE_COLUMNS Order

The canonical column order below must be preserved exactly when applying the saved pipeline artifacts (preprocessing_pipeline.joblib and pca_model.joblib) to new data. Reordering the columns will produce incorrect transformed values and invalid PCA projections.
FEATURE_COLUMNS = [
    'pl_orbper',
    'pl_orbsmax',
    'pl_rade',
    'pl_bmasse',
    'pl_orbeccen',
    'pl_insol',
    'pl_eqt',
    'st_teff',
    'st_rad',
    'st_mass',
    'st_met',
    'st_logg',
]

High-Imputation Warning

pl_insol has very high imputation in the working sample. Although the raw null rate for insolation flux is 57.58% across the full 910-planet dataset, within the 731 planets retained after the completeness filter, 51.71% of pl_insol values are imputed by KNNImputer. KNN imputation was shown to outperform median imputation on held-out complete cases, but this level of synthetic fill-in means that cluster interpretations centred on insolation flux — for example, comparisons of received stellar energy between the two planetary families — should be made with caution and treated as indicative rather than definitive.

Build docs developers (and LLMs) love