Skip to content

PFile.compute_zeff aliases Z_main onto the impurity for two-entry ion blocks (silent 10x Zeff) #19

Description

@d-burg

PFile.compute_zeff reads Z_main = Z[-2] (bouquet/io/pfile.py:579). For a natural two-entry ion block [impurity, main], index [-2] lands back on the IMPURITY, so the computed Zeff comes out ~27 instead of ~2.5 on a carbon plasma — silently, with no warning.

Discovered 2026-08-05 while synthesising per-beta p-files for the 169510 beta-scan ensembles (binary IDA sources skip the p-file rebuild — is_binary_profile_source — so p-files had to be written fresh via the PFile writer). The error was caught ONLY by round-tripping the written file against the archive; with a three-entry [impurity, main, beam] block the synthesised Zeff matches the archive to 2e-4 and all four kinetic channels to ~3e-5.

Every downstream consumer of a two-entry p-file gets a plasma with ~10x the real impurity content — the bootstrap, the pressure assembly, and any Zeff-primary density derivation would all be wrong.

Suggested fix: identify the main ion by charge/mass (Z==1 or the A,Z pair) rather than by position, or at minimum validate that the block ordering assumption holds and raise when it cannot be determined. A regression test with a two-entry block asserting Zeff ~ the physical value would have caught this.

Workaround in the beta-scan harness: always write three-entry ion blocks (see run_beta_ensembles.py in CTM-processing/bouquet_paper/beta_scan_169510).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions