You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Triage 31 Oct 2026: two bullets are done: the downward family rule and the uncorroborated tier (PR #46), and the proposer's own axis refinement (PR #47). Still open: the overlap check, Mn on the Al alloys (Paul's word), the line tail beside a dominant K line, and the self-pair half bound on sum peaks.
Auto ID (ElementProposer.proposeOnRefinedAxis, file axis, no elements listed) on the public AlMgSi demo set (demo-edx, generator sim_edx.py v2.0): planted truth on synthetic data. Planted: Al, Mg, Si, O (oxide), stray Cu K, sum peaks; no Mn, Ar, Ag or Ta.
Found: Al, Si (ladder L5, matrix map); Mg, Si, O (L6, precipitate); Mg, Si (L7, pure Mg5Si6). The proposer's axis refinement ran on its own K picks.
Proposed falsely: Ta (4.3 L_D) on the recipe-A map pool. Ta M-alpha (1.71 keV) sits on the unclaimed Si K-alpha (Si is not proposed there: its truth is 2.8 L_D). The Ta L-alpha confirmation line (8.15 keV) lies next to the stray Cu K-alpha, so the family rule does not withhold it. This is the open overlap-check bullet.
Possible, not proposed: Ar (12-57 L_D) and Ag (4-23 L_D) on every Al-rich pool. Both are the Al+Al sum peak at 2.973 keV. They are not shown as a sum-peak question, because only proposed candidates get that test. This is the self-pair sum-peak bullet: possible candidates should get the same question.
Missed: Mg in the matrix pools (planted at 1.1 L_D on recipe A, so missing it is fair; on the matrix map it is lost to the Al K-alpha tail bias) and O (1.3 L_D).
Mn: never proposed; not a candidate, or a withheld candidate at 0.0 L_D on L6. No false Mn.
Cu (grid):ElementRole.fitOnly keeps the Cu lines in the fit and out of wt% and at%, the exSpy way; the proposer adds a named grid conflict, and with a hole spectrum says whether Cu is also on the hole. Not covered by either SpectroKit or exSpy: subtracting the hole-region Cu from a sample that also holds Cu. The demo cannot test it (its vacuum region holds 6 counts).
open: LineTail is opt-in in the fit; the proposer does not use it yet
waits (see below)
Mn on the Al alloys
Mn is an unknown like any element: the loop reports it or rules it out with its limit. Demo: never proposed, Currie limits 0.04 to 0.14 at% (see #15)
nothing to change
Subtracting the hole-region Cu from a sample that also holds Cu
open, a new feature; the demo cannot test it (6 counts in its vacuum)
not started
False Ta. The demo pools are planted truth on synthetic data. ElementProposer().proposeOnRefinedAxis at main e91a75a proposes no Ta on any of the five demo pools, on Poisson counts or on the noise-free x100 spectra. The #54 head gives the same result with the overlap check on or off. That check does not act here: it fits only elements outside the model, and Ta was nominated by its own residual peak. On recipe A, Ta M-alpha (3.3 L_D) and Si K-alpha (4.4 L_D) tie for the 1.727 keV peak, so both stay possible and the planted Si is not proposed. Hypothesis: the Ta trial passes its L-alpha confirmation (8.15 keV) on the stray Cu K-alpha (8.05 keV), which is unmodelled at that point. Ruling Ta out there would give the peak to Si. What would refute it: Ta still passes the confirmation once Cu is in the model.
Mg and O. Neither is even a candidate at the default bars. The residual peak needs 5 sigma (7.5 below 1 keV), and a new element needs a gain of 100. At 3 sigma with no low-energy factor, the matrix map nominates Mg (1.03 L_D) and O (2.05 L_D), and both fail the gain bar (12 and 47). On the noise-free x100 spectra every pool proposes both. Lowering the bars would depart from the published method, so nothing changes.
Why the loop items wait.ElementProposer.swift is already in more than two open PRs (#54, #61 and the line-weight PR), so the Si/Ta tie and the proposer side of the line tail come after those land.
Activity
Paullo9 commentedon Oct 31, 2026
Triage 31 Oct 2026: two bullets are done: the downward family rule and the uncorroborated tier (PR #46), and the proposer's own axis refinement (PR #47). Still open: the overlap check, Mn on the Al alloys (Paul's word), the line tail beside a dominant K line, and the self-pair half bound on sum peaks.
Generated by Claude Code
Paullo9 commentedon Oct 31, 2026
Auto ID (
ElementProposer.proposeOnRefinedAxis, file axis, no elements listed) on the public AlMgSi demo set (demo-edx, generatorsim_edx.pyv2.0): planted truth on synthetic data. Planted: Al, Mg, Si, O (oxide), stray Cu K, sum peaks; no Mn, Ar, Ag or Ta.Found: Al, Si (ladder L5, matrix map); Mg, Si, O (L6, precipitate); Mg, Si (L7, pure Mg5Si6). The proposer's axis refinement ran on its own K picks.
Proposed falsely: Ta (4.3 L_D) on the recipe-A map pool. Ta M-alpha (1.71 keV) sits on the unclaimed Si K-alpha (Si is not proposed there: its truth is 2.8 L_D). The Ta L-alpha confirmation line (8.15 keV) lies next to the stray Cu K-alpha, so the family rule does not withhold it. This is the open overlap-check bullet.
Possible, not proposed: Ar (12-57 L_D) and Ag (4-23 L_D) on every Al-rich pool. Both are the Al+Al sum peak at 2.973 keV. They are not shown as a sum-peak question, because only proposed candidates get that test. This is the self-pair sum-peak bullet: possible candidates should get the same question.
Missed: Mg in the matrix pools (planted at 1.1 L_D on recipe A, so missing it is fair; on the matrix map it is lost to the Al K-alpha tail bias) and O (1.3 L_D).
Mn: never proposed; not a candidate, or a withheld candidate at 0.0 L_D on L6. No false Mn.
Cu (grid):
ElementRole.fitOnlykeeps the Cu lines in the fit and out of wt% and at%, the exSpy way; the proposer adds a named grid conflict, and with a hole spectrum says whether Cu is also on the hole. Not covered by either SpectroKit or exSpy: subtracting the hole-region Cu from a sample that also holds Cu. The demo cannot test it (its vacuum region holds 6 counts).Paullo9 commentedon Oct 31, 2026
What is left on #9, and where each item is covered (1 Nov 2026)
ProposerPolicy.overlapCheckexplainedBySumPeakLineTailis opt-in in the fit; the proposer does not use it yetFalse Ta. The demo pools are planted truth on synthetic data.
ElementProposer().proposeOnRefinedAxisat main e91a75a proposes no Ta on any of the five demo pools, on Poisson counts or on the noise-free x100 spectra. The #54 head gives the same result with the overlap check on or off. That check does not act here: it fits only elements outside the model, and Ta was nominated by its own residual peak. On recipe A, Ta M-alpha (3.3 L_D) and Si K-alpha (4.4 L_D) tie for the 1.727 keV peak, so both stay possible and the planted Si is not proposed. Hypothesis: the Ta trial passes its L-alpha confirmation (8.15 keV) on the stray Cu K-alpha (8.05 keV), which is unmodelled at that point. Ruling Ta out there would give the peak to Si. What would refute it: Ta still passes the confirmation once Cu is in the model.Mg and O. Neither is even a candidate at the default bars. The residual peak needs 5 sigma (7.5 below 1 keV), and a new element needs a gain of 100. At 3 sigma with no low-energy factor, the matrix map nominates Mg (1.03 L_D) and O (2.05 L_D), and both fail the gain bar (12 and 47). On the noise-free x100 spectra every pool proposes both. Lowering the bars would depart from the published method, so nothing changes.
Why the loop items wait.
ElementProposer.swiftis already in more than two open PRs (#54, #61 and the line-weight PR), so the Si/Ta tie and the proposer side of the line tail come after those land.🤖 Generated with Claude Code