MESAlab: Pipeline for Blue Loop Analysis

• MESAlab is a Python-based pipeline that post-processes MESA output data to automatically detect the blue loop phase in intermediate-mass stars.
• It integrates modules for data ingestion, metadata management, visualization (HRD/CMD), and preparation of asteroseismic inlists like GYRE and RSP.
• The tool is optimized for high-throughput, reproducible analysis across large stellar grids with configurable phase-detection thresholds and bolometric corrections.

Searching arXiv for the specified paper and directly related MESA references. arXiv_search("(Tarczay-Nehéz, 10 Sep 2025) MESAlab a Pipeline for Mapping the Blue Loop with MESA runs") arXiv_search("Modules for Experiments in Stellar Astrophysics MESA Jermyn 2023 arXiv") mesalab, presented as MESAlab, is a Python-based pipeline for simplifying the post-processing of Modules for Experiments in Stellar Astrophysics (MESA) outputs by automatically identifying stellar evolutionary phases, with a specific focus on the blue loop: a blue-ward excursion in the Hertzsprung-Russell Diagram (HRD) for intermediate-mass stars often associated with peculiar pulsational phenomena like “strange modes” (Tarczay-Nehéz, 10 Sep 2025). It is positioned not as a stellar-evolution solver itself, but as a modular, largely data-driven layer over large MESA grids, designed for automated phase finding, visualization, bolometric corrections, and downstream asteroseismological preparation.

1. Scope and conceptual role

MESAlab is built around the practical problem that many MESA studies use computational grids covering thousands of models, requiring substantial time and computational effort to process (Tarczay-Nehéz, 10 Sep 2025). Its central purpose is therefore post-processing at scale: reading MESA outputs, organizing metadata, detecting blue loops, generating HRD and color-magnitude diagram (CMD) products, and preparing models for GYRE and RSP calculations.

A useful distinction is that MESA provides the stellar evolution calculations, whereas mesalab operates on the resulting history.data and profiles.index products. This distinction is essential because the package’s logic is framed in terms of parsing existing runs, constructing tabular representations, and emitting derived catalogs and plots rather than evolving stellar models. A common misunderstanding would be to treat mesalab as an alternative to MESA; the paper instead defines it as a pipeline for analysis of MESA outputs (Tarczay-Nehéz, 10 Sep 2025).

The package’s scientific emphasis is the mapping of blue loops in intermediate-mass stars. In this context, the blue loop is treated as a recognizable phase in the HRD trajectory that can be detected algorithmically from time series of effective temperature and luminosity. This makes mesalab relevant both for large grid surveys and for workflows in which blue-loop segments become inputs to pulsation studies.

2. Pipeline architecture and execution model

The core design is explicitly modular and largely data-driven. The paper identifies five principal components, each associated with a distinct stage of the workflow (Tarczay-Nehéz, 10 Sep 2025).

Component	Function
Data ingestion (“reader”)	Uses py_mesa_reader to parse history.data and profiles.index
Metadata management	Writes metadata.json per run and a central runs_index.csv
Phase-finding engine	Detects blue loops from $T_{\rm eff}(t)$ and $L(t)$ arrays
Visualization & bolometric-correction module	Computes Gaia $G$, $G_{\rm BP}$, $G_{\rm RP}$ and generates HRDs/CMDs
Asteroseismology driver	Writes GYRE and RSP inlists and optionally dispatches jobs

For each grid point, defined as a combination of initial mass $M$ and metallicity $Z$, mesalab creates a subdirectory named M{mass}_Z{metallicity}. Within that directory it records run-level information in metadata.json, including inlist tags such as mixing length $\alpha_{\rm MLT}$, initial $Y$, network choice, and the paths to history.data and the profile outputs. A central runs_index.csv aggregates processed runs and their key metadata for bookkeeping (Tarczay-Nehéz, 10 Sep 2025).

The typical invocation is given as:

$G_{\rm RP}$3

The corresponding workflow is sequentially defined as: walking subdirectories, reading history.data and profiles.index, writing metadata.json per run, detecting blue loops, producing HRDs/CMDs and bolometric-correction tables, and optionally launching GYRE or RSP (Tarczay-Nehéz, 10 Sep 2025). This structure suggests a pipeline optimized for reproducible batch processing of precomputed stellar grids rather than interactive single-track inspection.

3. Blue-loop detection algorithm

MESAlab formalizes blue-loop identification through derivative-and-threshold tests on the history arrays. The defining characteristic is described as a temporary reversal of the usual red-giant cooling trend, namely an excursion to higher $T_{\rm eff}$ at roughly constant or slightly reduced luminosity (Tarczay-Nehéz, 10 Sep 2025).

Let $L(t)$0 and $L(t)$1 denote the effective temperature and luminosity at time step $L(t)$2. The pipeline computes

$L(t)$3

$L(t)$4

A candidate upturn, interpreted as the loop start, satisfies

$L(t)$5

A matching downturn, interpreted as the loop end, is found when

$L(t)$6

The total temperature excursion across the loop is defined as

$L(t)$7

with the requirement

$L(t)$8

The paper also presents the core criteria in LaTeX form as

$L(t)$9

$G$0

The thresholds $G$1, $G$2, and $G$3 are set in the configuration file, with defaults of $G$4, $G$5, and $G$6 (Tarczay-Nehéz, 10 Sep 2025). The implementation is therefore intentionally simple and configurable. A plausible implication is that the method is designed for transparent phase labeling across large ensembles, where interpretability and throughput can be more important than a highly specialized classifier.

4. Data structures, configuration, and emitted products

The package uses a straightforward in-memory representation. Each run’s history is loaded into a pandas.DataFrame with columns including ['model_number','star_age','star_log_L','star_teff',…], and detected loops are stored as a list of dictionaries of the form {'run':…, 'start_model':i, 'end_model':j, 'ΔTeff':…} (Tarczay-Nehéz, 10 Sep 2025). The core Python stack is explicitly given as numpy for vectorized arithmetic, pandas for tabular metadata, matplotlib for static plots, and optionally h5py to cache large arrays in HDF5.

A representative directory layout is:

$G_{\rm RP}$4

A representative configuration file is:

$G_{\rm RP}$5

The output structure under analysis/ includes runs_index.csv, per-run metadata.json, blue_loops.csv, HRD.png, CMD_Gaia.png, gyre_inlist_*.txt, rsp_inlist_*.txt, gyre_logs/, rsp_logs/, and a global all_loops.h5 store of loop segments for bulk analysis (Tarczay-Nehéz, 10 Sep 2025).

These choices indicate a design that prioritizes auditability. The CSV and JSON products preserve phase labels and run metadata in human-readable form, while the HDF5 store supports repeated analysis without reparsing raw outputs. This suggests a pipeline suitable for parameter sweeps in which thresholds or downstream selections are adjusted iteratively.

5. Visualization, bolometric corrections, and asteroseismology integration

Once loops are identified, mesalab computes Gaia $G$7, $G$8, and $G$9 magnitudes by interpolating the MIST bolometric-correction tables using cubic-spline interpolation in $G_{\rm BP}$0, $G_{\rm BP}$1, and $G_{\rm BP}$2 (Tarczay-Nehéz, 10 Sep 2025). It then automatically generates annotated HRDs and CMDs.

The HRD plotting routine overlays the full evolutionary track in black and the detected blue-loop segment in red, labeling the segment by the total $G_{\rm BP}$3. The paper states that the resulting figure shows the full evolutionary track in black, with the blue-loop excursion overplotted in red and annotated with the total $G_{\rm BP}$4 (Tarczay-Nehéz, 10 Sep 2025). The axis conventions include an inverted $G_{\rm BP}$5 axis, consistent with standard HRD presentation.

The asteroseismology driver extends the pipeline from phase identification to simulation setup. For each flagged blue-loop model, mesalab writes GYRE and RSP inlist files from templates plus user-supplied overrides, then optionally submits them either to a local SLURM installation or to a Python multiprocessing.Pool for parallel execution. If SLURM or PBS environment variables are detected, job-array scripts are emitted instead (Tarczay-Nehéz, 10 Sep 2025).

This coupling of phase-finding and seismology preparation is central to the package’s scientific role. The blue loop is not treated merely as a visual feature in the HRD; it becomes a machine-identifiable gateway to downstream pulsation analysis. In that sense, mesalab links stellar-evolution grids, photometric transformations, and asteroseismic tooling within a single batch-oriented workflow.

6. Performance characteristics, applications, and stated extensions

The paper reports benchmark tests on a grid of approximately $G_{\rm BP}$6 MESA runs, each approximately $G_{\rm BP}$7 of history and profile data, executed on a 16-core workstation (Tarczay-Nehéz, 10 Sep 2025). Under these conditions, data ingestion and phase detection required approximately $G_{\rm BP}$8 minutes, or approximately $G_{\rm BP}$9, using $G_{\rm RP}$0 cores in parallel; writing bolometric corrections and HRDs required approximately $G_{\rm RP}$1 additional minutes; and end-to-end processing, including GYRE inlist generation but excluding actual GYRE execution, required approximately $G_{\rm RP}$2 minutes. The I/O strategy is described as optimized by reading only the four necessary columns from history.data, and intermediate arrays can optionally be cached in a single HDF5 store to avoid repeated parsing when thresholds are reconfigured (Tarczay-Nehéz, 10 Sep 2025).

The current scientific focus is blue loops in intermediate-mass stars, but the framework is described as extensible. The paper specifically lists possible extensions to core-helium-flash detection through sudden spikes in the He-burning luminosity column such as L_he4, dredge-up event identification through tracking surface abundances of CNO isotopes, and integrations into asteroseismic pipelines beyond GYRE, including automatic post-processing of GYRE eigenfunctions, computation of mode inertia, or feeding structural models into ADIPLS (Tarczay-Nehéz, 10 Sep 2025).

Because mesalab emits both CSV/HDF5 catalogs of phase timestamps and annotated plots, it is presented as readily chainable into larger workflows for population synthesis, machine-learning classification of evolutionary phases, or direct comparison with Gaia CMDs (Tarczay-Nehéz, 10 Sep 2025). The manuscript therefore situates the package at the interface between large-grid stellar evolution, diagnostic visualization, and automated downstream analysis. At the same time, the stated extensions remain extensions: the documented implementation centers on blue-loop detection, bolometric-correction generation, and preparation of GYRE and RSP inputs rather than a general-purpose evolutionary-phase ontology.