| OPN-01 |
Radial potential at 0.15 M: the text quotes −14/−47 mV, the appendix table −29/−57 mV |
Author |
Use of the radial potential as a regression target; excluded from Tier 3 and Tier 4 targets until settled |
| OPN-02 |
Location of the author's contour script. Closed, 26 September 2026 (WP20 plan, Design §1). It is create_polygon_contour in the author's pqr2grid, first committed 7 October 2019. It takes the first contour found at 0.25, applies Shapely simplify(0.1) and writes at %.2f, with no smoothing, spacing step or gate. Its radial binning places column j at jh, where the bin's centre is (j + ½)w, with w = (2L + 1)h/(2L + h). That is an index-to-radius erratum (knowledge/04-clya-geometry-and-charge/01-geometry-pipeline-as-executed.md#12-the-authors-contour-script-read). The WP20 plan, D2, records what ports |
Closed |
Closed |
| OPN-03 |
PlyAB supporting-information details: analyte relative permittivity, per-position mesh strategy (remesh against ALE), barrier heights in kT, electro-osmotic flow velocities |
Author, from the retained model files |
Analyte force regression targets and adoption of PlyAB as a second reference case after v1.0 |
| OPN-04 |
ClyA-AS mutation list: 8 mutations relative to the S. typhi wild type in one place, 27 relative to the E. coli 2WCD structure in another. Both internally correct |
Author, with the structure-preparation stage |
Provenance of Q_net (FR-12); the structure-preparation stage must record which list was applied to which PDB |
| OPN-05 |
Pore-polygon vertex table. Delivered as data/geometry/clya_as_radial_geometry.csv, 185 vertices, extents as published. Closed by the author, 5 September 2026: the delivered table is the geometry of record, and the model report's 190 is the count after COMSOL's import conditioning. §2.2 and §5.2.1 are amended to it; the §5.2.1 fixture, mesh/reference.py and VAL-05 all cite it |
Closed |
Closed |
| OPN-06 |
Attribution of the reference's own charge-conservation gap: −72.9 e against −72 e atomistic is 1.25 %, twelve times QR-03's budget. Answered from the delivered rhoq_pore table, 6 September 2026: it is the consumer's. The table's own planar integral is −71.999999999663 e, exact to 4.7 × 10⁻¹², so the producer leg is not where the 1.25 % went, and the published net charges are not different constructs on this axis. Our own consumer leg on a comparable mesh is −0.99 % by the same interpolate-and-integrate route — the same size and character, opposite sign — which is aliasing of a sub-element-scale field, not lost charge (§4.4 NOTE) |
Closed |
Closed: any Tier-3 comparison of pore charge (VAL-06, WP13) compares two consumer legs, and ours is gated ten times more strictly than the reference achieved |
| OPN-07 |
A golden's case_hash does not identify a deposited fixed charge. validation/comsol.py case_identity hashes ResolvedCase.solve_provenance, whose fields.charge says only whether inputs.charge was supplied. It replaces a supplied field with its contents' record (VAL-03), and on that rule two cases that differ only in their charge table are two cases. Since WP28 (FR-13, FR-14), stage 7 deposits a charge from structure: or inputs.pqr, and that charge reaches no key in the solve provenance. Its structure, charge.ph, charge.forcefield, charge.titration and charge.smearing are all invisible to the identity, and fields.charge reads False. [tested] on examples/06-pdb-to-mesh/2wcd.case.yaml, 1 October 2026: pH 7.5 (default), pH 5, pH 9 and smearing.sharpness 0.8 all give case_hash 8559ee13…; only the model moves it. Such a case is therefore indistinguishable from the same physics on a supplied mesh with no fixed charge at all. A χ that stage 7 derives (§4.4 NOTE on the derived solid fraction; WP30) is invisible in the same way, and for the same reason it does not set fields.eps_r. Found by the WP28 review (PR #57, finding #7). The solve's own key is not affected, because the stage-7 artefact's hash already carries the protonation and the deposit (§5.3.2). The decision for the WP that resolves it: what represents a deposited charge in the identity. The candidates are the stage-7 inputs (the protonation key and the smearing parameters, not the mesh, which §7.4 deliberately leaves out), or the export lattice's grid digest, as a supplied field contributes it. Constraints: do not do it by setting fields.charge true in the provenance, which would move every producer case's solve key; leave every non-producer case's identity unchanged; and test it with a test_val03_… that fails on the example above Representation decided by the author, 3 October 2026 (§8.2.5 E3): the stage-7 recipe, with the lattice spacing and the element order left out as discretisation. Closed, 4 October 2026 (WP34). case_identity adds a key deposited_charge to a depositing case's record, holding the stage-1 key's parameters, the protonation key's parameters without gates and its input digests, and the kernel's parameters without grid_spacing_nm. It adds a key derived_eps_r to a deriving case's, holding derived_parameters and the stage-1 key's parameters, and a key exclusion_shell to a case with a non-zero charge.exclusion_offset_nm, holding the offset. The recipe is built through the stages' own key functions without running a stage, or, for a finished run, read from the stage-1 and protonation artefacts the run recorded (ReopenedRun.upstream), so validate compare and export-golden neither depend on the working directory nor follow a structure file edited after the run. [tested] test_val03_case_identity_names_a_deposited_charge on the example above: the four cases give four hashes, grid_spacing_nm and the element order give the default's, and two PQRs differ where a moved copy does not. …_ignores_the_protonation_gate_tolerances, …_names_the_exclusion_shell, …_run_identity_is_read_from_the_recorded_artefacts and …_reopen_reads_the_runs_own_upstream_artefacts cover the rest. Non-producer identities, every solve key and fields.charge are unchanged |
Closed |
Closed |
| OPN-08 |
The content and gate of the stable v1.0 release, now that the validation phase is released before it, as v0.7 and Phase 6 (§8.2.5 E2; §8.2.6 F1). IF-01's stability promise is v1.0's, and the case schema and public API may change until then (§8.2.6 F4) |
Author |
Nothing before v1.0. The §2.7 row for v1.0 and any requirement retagged to it |
| OPN-09 |
When to support Python 3.15, and whether to adopt its lazy imports (PEP 810) in place of VER-72 (a)'s function-level imports. Not adopted on 11 October 2026, because five dependencies had no 3.15 wheels and import cost is not what makes the gate slow (§8.2.10 J6). Support follows once every dependency ships 3.15 wheels; lazy imports are reconsidered when Python 3.11 reaches end of life (October 2027) or at v1.0, whichever is first |
Author |
Nothing on the v0.7 path |