---
title: 'MESAlab: Pipeline for Blue Loop Analysis'
url: https://www.emergentmind.com/topics/mesalab
type: topic
---

# MESAlab: Pipeline for Blue Loop Analysis

Searching arXiv for the specified paper and directly related MESA references.
arXiv_search("2509.08946 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” [2509.08946]. 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 [2509.08946]. 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 [2509.08946].

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 [2509.08946].

| 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 [2509.08946].

The typical invocation is given as:

```bash
mesalab process --input /path/to/mesa/grid --config mesalab.yaml --outdir analysis
```

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 [2509.08946]. 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 [2509.08946].

Let $T_{\rm eff}(i)$ and $L(i)$ denote the effective temperature and luminosity at time step $i$. The pipeline computes
$$
\Delta T_{\rm eff}(i) = T_{\rm eff}(i+1)-T_{\rm eff}(i),
$$
$$
\Delta \log L(i) = \log L(i+1)-\log L(i).
$$

A candidate upturn, interpreted as the loop start, satisfies
$$
\Delta T_{\rm eff}(i) > \delta T \quad \text{and} \quad \Delta \log L(i) > -\delta L.
$$

A matching downturn, interpreted as the loop end, is found when
$$
\Delta T_{\rm eff}(j) < -\delta T \quad \text{and} \quad \Delta \log L(j) \approx 0.
$$

The total temperature excursion across the loop is defined as
$$
\Delta T_{\rm eff,loop} =
\max_{k\in[i,j]} T_{\rm eff}(k) - \min_{k\in[i,j]} T_{\rm eff}(k),
$$
with the requirement
$$
\Delta T_{\rm eff,loop} > \delta T_{\min}.
$$

The paper also presents the core criteria in LaTeX form as
$$
\exists\, i<j :
T_{\rm eff}(i+1)-T_{\rm eff}(i) > \delta T,
\quad \log L(i+1)-\log L(i) > -\delta L,
$$
$$
\Delta T_{\rm eff,loop} =
\max_{k\in[i,j]}T_{\rm eff}(k)\;-\;\min_{k\in[i,j]}T_{\rm eff}(k)
> \delta T_{\min}.
$$

The thresholds $\delta T$, $\delta L$, and $\delta T_{\min}$ are set in the configuration file, with defaults of $\delta T = 50\,\mathrm{K}$, $\delta L = 0.01\,\mathrm{dex}$, and $\delta T_{\min} = 200\,\mathrm{K}$ [2509.08946]. 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':…}` [2509.08946]. 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:

```text
mesa_grid/
  M1.5_Z0.014/
    history.data
    profiles.index
  M2.0_Z0.014/
    …
```

A representative configuration file is:

```yaml
δT:        100    # K
δL:        0.02   # dex
δT_min:    300    # K
bolcor:    MIST   # BC tables
run_seismo: True
parallel:  8      # cores
```

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 [2509.08946].

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$, $G_{\rm BP}$, and $G_{\rm RP}$ magnitudes by interpolating the MIST bolometric-correction tables using cubic-spline interpolation in $T_{\rm eff}$, $\log g$, and $[\mathrm{Fe}/\mathrm{H}]$ [2509.08946]. 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 $\Delta T_{\rm eff}$. 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 $\Delta T_{\rm eff}$ [2509.08946]. The axis conventions include an inverted $T_{\rm eff}$ 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 [2509.08946].

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 $1\,200$ MESA runs, each approximately $200\,\mathrm{MB}$ of history and profile data, executed on a 16-core workstation [2509.08946]. Under these conditions, data ingestion and phase detection required approximately $8$ minutes, or approximately $4\,\mathrm{s/run}$, using $8$ cores in parallel; writing bolometric corrections and HRDs required approximately $3$ additional minutes; and end-to-end processing, including GYRE inlist generation but excluding actual GYRE execution, required approximately $12$ 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 [2509.08946].

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 [2509.08946].

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 [2509.08946]. 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.

Source: https://www.emergentmind.com/topics/mesalab