Add magnon-dispersion-bec task

[wenjun-ke]

Summary

Adds tasks/magnon-dispersion-bec, a magnonics task combining dipole-exchange spin-wave dispersion parameter extraction with pumped magnon-gas thermodynamics.

Part A — dispersion parameter extraction. From an in-plane magnetized YIG film's measured FMR frequency and spectral minimum, infer 4πM, the exchange stiffness D, and k_min. Then forward-predict, from the same material parameters, the surface (θ=π/2) branch frequency at a given wavevector and a second film's spectral minimum.

Part B — pumped magnon gas. A 3D exchange-dominated magnon gas at 300 K under parametric pumping, treating pumping as rapid thermalization that conserves magnon number and total energy. Three interlocked configurations: a sub-critical pumped gas (chemical potential, pumped temperature, BEC threshold, T^3/2 density scaling), a supercritically pumped gas that condenses (condensate fraction on the μ=ε_min branch), and a third whose exchange stiffness is the value extracted in Part A — so a Part-A error propagates into Part B.

The task is self-contained: every numerical input is in task.md, with no bundled data files. Output is a single fenced RESULT block in /root/result.md with 21 named numeric fields.

Contents

• task.md — human-authored prompt, no skill hints, explicit output contract.
• environment/ — python:3.12-slim Dockerfile with pinned numpy/scipy/matplotlib/pytest.
• environment/skills/magnon-gas-thermodynamics/ — one mentor skill (SKILL.md + references/model.md).
• oracle/ — solve.py + magnon_physics.py, deriving all 21 values by computation; oracle/provenance/manifest.json records the source model and primary references (Stancil & Prabhakar; Chumak et al. 2015; Demokritov et al. 2006; Serga et al. 2010).
• verifier/ — test_outputs.py recomputing the quantities and comparing with tolerance bands.

Registration touches two files outside the task directory: the registry.json entry (digest computed with the published task_digest construction) and the task name in .github/scripts/validate_repository.py's EXPECTED_TASKS.

CI validators all pass locally: validate_repository.py, validate_tasks.py tasks, lint_skill_frontmatter.py, test_lint_skill_frontmatter.py, lint_frontierphysics_docs.py, and ruff@0.14.10 on the changed Python files.

Evaluation

Oracle: reward 1.0 (bench eval run --agent oracle --sandbox docker).

Run	Model	Result
smoke-haiku-magnon	Haiku 4.5	0/1
eval-haiku-magnon-high	Haiku 4.5 (high)	0/1
ns-sonnet-magnon-high	Sonnet 5 (high)	0/1
eval-opus-magnon	Opus 4.8	1/1
eval-opus-magnon-high	Opus 4.8 (high)	0/1
ns-opus-magnon-high-v2	Opus 4.8 (high)	1/1
eval-opus-magnon-withskill	Opus 4.8	0/1
ws-opus-magnon-v2	Opus 4.8	1/1

The with-skill control passes (ws-opus-magnon-v2), so the task is solvable and the instructions, dependencies, and verifier assumptions hold together.

Open issues, flagged for reviewers

I'd rather surface these than have a reviewer find them.

1. The no-skill difficulty gate does not currently hold. Opus 4.8 solved this in the no-skill condition on two separate runs (eval-opus-magnon, ns-opus-magnon-high-v2), against one no-skill failure at high reasoning. The review bar asks for tasks that are "independently hard in the no-skill condition," and the primary benchmark score is the no-skill number — by that standard this task is not yet calibrated, and the Opus no-skill result is not a fluke of a single trial. Haiku 4.5 and Sonnet 5 do fail it. Every cell is a single trial, so these are indicative rather than converged rates. If the bar is "fails the strongest current model without skills," this needs deepening before merge; happy to take direction on whether that blocks or whether more trials should come first.

2. The verifier is not independent of the oracle. verifier/magnon_physics.py and oracle/magnon_physics.py are byte-identical apart from one docstring word ("verifier copy" vs "oracle copy"). The provenance manifest describes the verifier as one that "independently imports" its physics core to recompute the quantities, which overstates the separation — in practice the verifier re-runs the oracle's implementation, so a modelling error in the shared core would be invisible to it rather than caught. The tolerance bands still guard against an agent's arithmetic drift, but not against the physics being wrong. Worth deciding whether an independently derived check is required here.

3. network_mode: public on a closed-form computation task. The task needs no network — all inputs are in the prompt and the image pins its dependencies at build time. Leaving the agent sandbox on public network weakens determinism and gives a route to the published literature the task is modelled on (Demokritov et al. 2006 and the other cited references). no-network looks like the safer setting. I left it as-is rather than change task semantics after the eval runs above were collected, since flipping it would invalidate them.

[vercel]

@wenjun-ke is attempting to deploy a commit to the Benchmarkthing Team on Vercel.

A member of the Team first needs to authorize it.