Reported issues for HYRR

Pod holds 19 of 24 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to HYRR.

Most discussed

spike: one version identity for the MCP surface (and settle the cargo install channel)

Spike. Design decision, not a bug fix. #599 is the symptom; this is the shape that produced it.

Motivation

ADR 0001 committed HYRR's MCP to one Rust SSoT, thin entry points, drift architecturally impossible, guarded by a byte-for-byte parity test across all three entry points. That worked: tool logic has genuinely not drifted.

Version identity was never brought under that principle. Three numbers claim to be "the version of HYRR's MCP", and which one you see depends on how you…

Read the thread · 2026-08-13 · open · outside contributor · 3 comments

MCP browser link (#config=) drops custom-alloy composition (+ density overrides + secondary_neutron) → online view can't reproduce the run

Summary

The simulate MCP tool returns a "View in browser" #config= link, but for any run that uses a define_material custom alloy, the encoded config stores only the material name — not its composition. The online app has no such (session-scoped) material, so the link renders a different/broken run. "Incl. the impurities" is exactly what's silently lost.

Repro

1. MCP define_material — an 11-element alloy, e.g. alsi10mg (Al bal, Si 10, Fe 0.55, Mn 0.45, Cu/Ni 0.05,…

Read the thread · 2026-07-20 · closed · outside contributor · 3 comments

hyrr-mcp: auto-fetch data on first invocation

Problem

hyrr-mcp/src/main.rs calls data_dir::resolve() (a pure read-only path lookup) and bails if nothing is found. The auto-download logic exists (core/src/data_fetch.rs — ensure_meta_stopping(), ensure_library()) but is only wired into the Tauri desktop binary's seed_cache_from_resources() + ensure_data() command — not the MCP entrypoint.

This means uvx hyrr-mcp is not one-shot installable. Users must manually pre-populate ~/.hyrr/nucl-parquet/ or set HYRR_DATA,…

Read the thread · 2026-05-20 · closed · outside contributor · 3 comments

hyrr-mcp reports version 0.1.0 — py-mcp/Cargo.toml is never bumped

Problem

The published hyrr-mcp package reports the wrong version to users:

$ uvx hyrr-mcp@0.19.0 --version
hyrr-mcp 0.1.0

Every release since the package existed reports 0.1.0. Confirmed against the live PyPI artifact:

$ uvx --from hyrr-mcp==0.19.0 python -c \
    "import importlib.metadata as m, hyrr_mcp; \
     print('dist:', m.version('hyrr-mcp')); print('native:', hyrr_mcp.__version__)"
dist:   0.19.0
native: 0.1.0

The distribution metadata is…

Read the thread · 2026-08-06 · closed · outside contributor · 2 comments

Spike: settle the TLS backend + CI runner strategy behind the aarch64 wheel failure (#461)

Motivation / why

release-hyrr-mcp.yml's linux-aarch64 leg has failed on every recent release — including the ones we called successful:

PyPI confirms it — hyrr-mcp 0.18.0 ships exactly four files:

[Read the thread](https://github.com/exoma-ch/hyrr/issues/573) · 2026-08-06 · closed · outside contributor · 2 comments

### MCP: structured data export (parquet/JSON) for full simulation inventory

## Problem

The MCP tools currently return markdown tables, lossy and per-tool. For any analysis beyond a single isotope I have to make many round trips and re-assemble in Python.

### Concrete example from a recent session

To compute F-18 + Sc-44 joint activity over a 24-h cooling tail with contaminant tracking and 511 keV purity, I had to:

- `get_isotope_production_curve` once per isotope (F-18, Sc-44, Sc-43, Sc-47, Sc-48) — 5 calls, 100 markdown rows each, parsed by hand
- `get_decay_data`…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/427) · 2026-06-01 · closed · outside contributor · 2 comments

### feat: offline-first data distribution — user stories + installer variants

## Problem

No single install path gives users a "download once, work offline forever" experience. The current tiers:

| Distribution | Data bundled | First-run download | Full offline? |
|---|---|---|---|
| **Hosted frontend** | Static CDN assets | 0 (browser fetches per-file) | Only with browser cache |
| **Tauri desktop** | meta+stopping (320 MB in installer) | XS library ~50 MB on first sim | Partial — depth preview yes, simulation no |
| **hyrr-mcp** | Nothing | Not wired (#245) | No |
|…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/264) · 2026-05-21 · closed · outside contributor · 2 comments

### natMg(p,x)24Na @ 17.8 MeV: TENDL-2025 evaluation ~10^4-10^5x below measured (EXFOR) cross-section — webapp vs. hyrr-mcp disagree on same data version

## Motivation / why

Reproduction: `p` at 17.8 MeV, natural Mg, 2 mm target, 20 µA, 1h irradiation, 1h cooling.

- **hyrrprd.ethz.ch (v0.20.1, data 2026.8.2)**: Na-24 via `25Mg(p,2p),26Mg(p,2pn)` — EOB 4.337 MBq, Sat. Yield 4.79 MBq/µA.
- **hyrr-mcp v0.20.1 (same reported data version, 2026.8.2)**: same beam/stack — Na-24 EOB ≈ 54 Bq, Sat. Yield 59.7 Bq/µA (24h-cooling activity 17.8 Bq).

Same code version, same pinned nuclear-data version, but the two surfaces disagree by **~80,000x** on this…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/669) · 2026-08-20 · open · outside contributor · 1 comment

## Most recent

### projectile 'n' without neutron_flux silently runs a 1e13 fission-fast default — not echoed in output (silent-default class, cf. #712)

## Summary

A `projectile: "n"` call that omits `neutron_flux` silently runs a **fission-fast spectrum at 1e13 n/cm²/s** (`parse_neutron_flux` → `FluxModel::Fast { flux: 1.0e13, temp_mev: 1.4 }`). The response never states which spectrum or flux was used. The numbers look plausible and are off by orders of magnitude. This is the same silent-default class as #712, but it survived because the default is intentional ("so the run still produces a sensible result rather than erroring").

## How I…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/725) · 2026-09-28 · open · outside contributor · 0 comments

### Layer density_g_cm3 override never applies to materials without a built-in density (resolve_material called with density_override=None): Tc, CaCO3, etc. error out

**Component:** hyrr-core `mcp/tools.rs`: layer parsing (`:1182`, `:1313`) and `tool_get_stopping_power` (`:1912`)
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. The documented override never gets a chance to apply, and the error message recommends a fix that doesn't work.

## TL;DR

The layer schema documents `density_g_cm3` as *"Override density [g/cm3] for this layer. Replaces the material's resolved density."* For any material hyrr has no built-in density for, the override…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/713) · 2026-09-28 · closed · outside contributor · 0 comments

### Unknown tool-argument keys silently ignored + undocumented 0.1 cm thickness default: thickness_mm gives a 10× thick target with no warning

**Component:** hyrr-core `mcp/tools.rs`: argument parsing for `simulate` and the stack-shaped tools
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. Silent input handling produces confidently wrong physics.

## TL;DR

Unknown keys are silently ignored at every level of the tool arguments. Combined with an undocumented default thickness, a unit-mistaken or misspelled field gives a plausible-looking but wrong result with no warning. The tool schemas declare no…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/712) · 2026-09-28 · closed · outside contributor · 0 comments

### Thermal neutron spectrum uses the Maxwellian density shape as flux: thermal (n,γ) over-predicted ~26% (4/π for 1/v)

**Component:** hyrr-core `neutron.rs::FluxModel::phi` (Thermal), consumed by `neutron_channel_rate`
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. Physics: thermal (n,γ) production is over-predicted by ~26% (4/π for a pure 1/v absorber).

## TL;DR

`FluxModel::Thermal` is documented and implemented as

φ(E) = flux·(2/√π)·√E/kT^{3/2}·exp(−E/kT) // neutron.rs:40, :71–77

That is the Maxwellian **density** distribution, n(E) ∝ √E·e^{−E/kT}, normalized to integrate…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/711) · 2026-09-28 · closed · outside contributor · 0 comments

### ensure_library never fetches the routed neutron / heavy-ion libraries (endfb-8.0, hi-xs-prod): n and heavy-ion runs silently empty out of the box

**Component:** hyrr-core `data_fetch.rs::ensure_library`. Callers: `hyrr-mcp/src/main.rs:111`, `py/src/lib.rs:460`, `py-mcp/src/lib.rs:83`
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. Silent, physics-relevant: neutron and heavy-ion runs are empty out of the box.

## TL;DR

`library_for_projectile()` (`core/src/db.rs:33`) routes neutrons to `endfb-8.0` and heavy ions to `hi-xs-prod`. But on a cold cache, `ensure_library(library)` extracts only `MANDATORY_PREFIXES` plus…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/709) · 2026-09-28 · closed · outside contributor · 0 comments

### Disk stack-result cache key omits data identity: an empty result computed on incomplete data outlives the data fix

**Component:** hyrr-core `mcp/cache.rs` (disk tier, #568)
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. A silently wrong result survives the fix to its cause.

## TL;DR

The on-disk stack-result cache (`~/.cache/hyrr/stack-results/`) is keyed on `CACHE_SALT | library | registry_fp | args`. The key doesn't include the **data**: not the resolved data root, not `DataSource`, not the data release or `data_sha256`. So a result computed against incomplete data keeps being served…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/708) · 2026-09-28 · closed · outside contributor · 0 comments

### feat(mcp): list hyrr-mcp in the official MCP Registry so agents can discover it

## Problem

`hyrr-mcp` is on PyPI (0.21.1) and works via `uvx hyrr-mcp`, but nothing lets an agent *find* it: `registry.modelcontextprotocol.io/v0/servers?search=hyrr` returns 0 servers. There is no `server.json`, no `mcp-name` ownership marker on PyPI, and no publish step. Every MCP client or directory that browses the official registry (or one of its mirrors) is blind to it; the only discovery path is a human reading our README.

## Plan

- `py-mcp/server.json`: name…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/706) · 2026-09-28 · closed · outside contributor · 0 comments

### secondary_neutron: downstream layer shows no neutron-induced activation (silent, e.g. Al-27(n,α)Na-24 behind a Be converter)

**Component:** hyrr-mcp / hyrr-core, `secondary_neutron` (ADR-0003 Phase 2)
**Version:** hyrr-mcp 0.20.1 (latest release as of filing), `tendl-2025` library
**Related:** #513 (Phase 2 tracker — claims "Secondary source magnitude ✅ E_p-dependent — folded from `(x,n)` xs against the degrading proton energy per layer"), #590 (explicitly lists "secondary-neutron" as one of three untested MCP paths where "a regression would be silent")
**Type:** bug (silent, physics-relevant under-reporting)

##…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/668) · 2026-08-19 · closed · outside contributor · 1 comment

### Data releases are not detected the way software releases are — and release-notes.json reports the wrong data_version for 0.19.0

## Short answer: no. A new **data** release is not noticed the way a new **software** release is.

Asked while tracing what `uvx hyrr-mcp` actually pulls. The two update paths are not symmetric, and one of them is currently reporting a wrong value.

### Software releases — actively detected

`core/src/update_check.rs` fetches `latest.json` from GitHub Releases (24 h cache TTL, 5 s timeout, `HYRR_DISABLE_UPDATE_CHECK` opt-out) and compares it to `hyrr_core::VERSION`. When newer,…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/606) · 2026-08-13 · open · outside contributor · 1 comment

### MCP: relative activity clamp (~1e-6 × peak EOB) silently drops long-lived minor-component products from the inventory

**Component:** hyrr-mcp / hyrr-core inventory step
**Version:** hyrr-mcp 0.18.0, data bundle `nucl-parquet-data-2026.7.1`, library `tendl-2023-iso`
**Related:** #130 (clamp negligible values — likely the origin), #528 (silent under-reporting)
**Type:** bug (silent, physics-relevant under-reporting)

## TL;DR

The inventory step drops any produced isotope whose **EOB activity is below ~1×10⁻⁶ of the run's peak isotope EOB activity**. The threshold is **relative to the peak, not absolute**, and…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/533) · 2026-07-21 · closed · outside contributor · 0 comments

### hyrr-mcp 0.18.0 auto-fetch broken: compiled DATA_VERSION `v0.15.0` (SemVer) has no matching CalVer data release → silent stopping/xs failure

## Summary
On **hyrr-mcp 0.18.0**, running **without** a pinned `--data-dir` (i.e. relying on auto-fetch) fails. The binary resolves `HYRR_DATA_VERSION = v0.15.0` and tries to fetch `nucl-parquet-data-v0.15.0`, but the nucl-parquet **data releases use CalVer** (`data-2026.7.1`, `data-2026.6.1`, …) — there is **no `v0.15.0` data release**. It pulls a little metadata into `~/.nucl-parquet/v0.15.0/` but can't get the parquet files, then errors on the first query.

## Repro
1. Config: `uvx --from…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/529) · 2026-07-17 · closed · outside contributor · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/exoma-ch/hyrr/issues).