Which FastHenry .inp deck syntax is read today, and which is not. This page is rendered from docs/fasthenry-compat.md at build time. For how results map to output files, see docs/output-formats.md.

FastHenry .inp format compatibility

fasterhenry's deck reader (fasterhenry-cli/src/inp.rs) accepts a subset of the public FastHenry .inp input-format description. This table is the line-by-line audit against that public description (issue #72, part of the 0.2.0 deck-compatibility epic, #76): every directive and framing rule the format documents, whether this reader supports it, and — for every difference — why.

Per this repository's clean-room rule (CONTRIBUTING.md), this audit and the reader itself are written from the public format description and self-authored example decks only; no FastHenry/FastCap source was consulted.

Status key:

• Supported — matches the public description.
• Supported, extended — matches, plus an additive feature the public format does not document (never a name the format already uses for something else).
• Supported, differs — intentionally different behavior, with the reason below.
• Supported (compat only) — accepted only under --fasthenry-compat; natively a line-numbered error.
• Deferred — tracked by a sibling issue in the same epic.
• Not supported — rejected with a line-numbered error; out of scope here.
• Not supported, permanent — rejected with a line-numbered error, and the rejection is a recorded decision rather than pending work; the reasoning is written out below the table it appears in.

Deck framing

.units

.default

Nodes (N)

Segments (E)

.external

.freq

.equiv

Ground planes (G, .hole, .contact)

Supported since issue #69. inp.rs's module documentation ("Ground planes: two G grammars") is the authoritative description; this table only records how each documented field maps.

Decision: contact rect reads both spellings, told apart by value count (issue #95)

Until issue #95 this reader spelled contact rect as two opposite corners, (x1, y1, z1, x2, y2, z2), mirroring hole rect. The documented clause is not that: like contact point, contact line, contact decay_rect and contact equiv_rect, it takes a centre, the rectangle's full widths about that centre and the largest cell wanted inside it — (x, y, z, xwidth, ywidth, xcell, ycell), seven values. hole rect really is two corners, but it belongs to the uniform plane syntax; the contact shapes belong to the non-uniform one, and the two conventions do not match. So a genuine third-party deck was rejected for its value count, and a six-value clause this reader accepted meant something other than what that spelling means in the documentation.

The decision: accept both, disambiguated by arity. Seven values are the documented centre/widths/cell form; six keep the corner meaning. Three reasons:

1. The counts cannot collide. Six and seven are distinct, so no deck is ambiguous and no clause changes meaning silently. The corner form is unreachable from the documented one and vice versa, which is what makes one clause name with two grammars safe here rather than a guess.
2. Nothing that parsed before changes meaning. The 0.2.0 goal is to read existing decks; a reader that silently re-interpreted the six-value form, or rejected it (option 2 in #95), would break decks written against earlier releases of this tool for no compatibility gain — the documented form is added either way.
3. Documenting the divergence permanently (option 3 in #95) leaves the gap open. A deck writing the documented seven values would still be rejected, which is precisely the drop-in-reading failure the epic exists to close.

The cost is one clause name with two grammars. It is paid down in the error: a value list that is neither six nor seven long is a line-numbered error naming both spellings, so a deck that miscounts is told what both are rather than nudged toward one.

On the status key above, the six-value row is Supported, extended rather than differs: the extension shares the documented clause's name but not its arity, so it shadows nothing the format documents — a deck writing the documented seven values always gets the documented reading. That is the narrow sense in which this is additive, and it is the whole reason arity is a safe discriminator here rather than a guess.

What the seven-value form means, exactly. It is contact decay_rect without the two outward limits, so it is read as one with both maxcells at the negative "no limit" sentinel: contact rect (x, y, z, xwidth, ywidth, xcell, ycell) is contact decay_rect (x, y, z, xwidth, ywidth, xcell, ycell, -1, -1). That follows from the shapes' own relationship — decay_rect is the rect that states its outward decay limits — and it means the contact decay_rect row above describes both: ceil(width/cell) fine cells per axis, the documented decay law 1/(1 − cell/width) outside, and cell required to be smaller than width. contact_rect_is_a_decay_rect_without_the_limits in fasterhenry-cli/src/inp.rs asserts the identity, and contact_rect_two_spellings_are_one_region asserts that the six-value corner form is the seven-value form at cell = width/2 (2 × 2 cells at ratio 2), so the two spellings genuinely name one clause.

The axes. xwidth/ywidth/xcell/ycell are read in the plane's own p1 → p2 / p2 → p3 coordinate system, exactly as contact decay_rect's are — because the documented seven-value form is a decay_rect without the outward limits (above), the two cannot disagree on what frame their shared xwidth/ywidth/xcell/ycell are stated in. Issue #118 settled that question fleet-wide, for contact point, line, decay_rect, equiv_rect and connection at once; this clause inherits the answer rather than needing its own, since it is one of them under a second name. The six-value corner form's two corners are not lengths and stay ordinary global coordinates, untouched by that decision. The grammar question #95 settles — corner pair versus centre and widths — is independent of it.

What would reopen this. Public documentation of a contact rect taking six values (which would collide with the extension and force it out), or a decision to drop this reader's non-documented extensions wholesale at a breaking release.

Decision: hole user1…user7 are rejected permanently (issue #99)

The format documents seven user-defined hole generators, hole user1 (val1, val2, …) … hole user7 (…). What they cut is a function the user writes and compiles into the tool; the deck carries only the generator's number and a bare value list. Nothing in the deck says what those values mean — they are arguments to a function this project does not have and, under the clean-room rule, may not go looking for.

That makes them unlike every other rejected shape in the table above. A diagonal contact trace is a shape whose public description disagrees with itself (issue #110, decided below) — a statement away, not a model away. A contact initial_grid was a shape whose value list was not pinned down here — one documented fact away, not a model away, and issue #113 has since read that fact out of the public description (the decision below). A contact circle is a shape the format does not have at all (issue #109, the decision below), which is a fact about the format rather than about this reader. A hole user3 is not a shape at all — no plane model, however general, lets a reader recover a meaning the deck never wrote down. So the rejection is not deferred work, and the error says so rather than pointing at a tracking issue that could never close.

Considered and declined: a predicate hole in the library. The obvious alternative (issue #99's option 1) was a further variant on fasterhenry::plane::Hole — Hole::Predicate(…), a caller-supplied Fn([f64; 2]) -> bool over cell centres — giving a program the arbitrary hole a deck cannot express. It was declined for three reasons:

1. The capability already exists, exactly, with no new API. GroundPlane::mesh does not depend on GroundPlane::holes — holes remove cells from the mesh, they never move its edges. So a caller can mesh the plane, apply any rule at all to the cell centres it reports, and cut each selected cell with a Hole::Point at its own centre; a centre lies strictly inside its own cell, so each point removes precisely that one cell. The composition is exact, not an approximation, and it holds on a graded mesh too (both are tested in fasterhenry/src/plane.rs, and the recipe is a doctest on Hole):

   let mesh = plane.mesh()?;
   for i in 0..mesh.nx() {
       for j in 0..mesh.ny() {
           let c = mesh.centre(i, j);
           if my_rule([c[0], c[1]]) {
               plane.holes.push(Hole::Point { at: [c[0], c[1]] });
           }
       }
   }
   

2. The useful form of the variant would cost the type's derives. A bare fn pointer keeps Hole: Copy + PartialEq but cannot capture anything — and a captured parameter list is the whole point of a user hole, so that form would not serve the motivating case. The form that does (a boxed or Arc-wrapped Fn) costs Copy and PartialEq on a type introduced one release ago, in exchange for a capability item 1 already provides.
3. It would be public API with no caller. The deck reader can never construct it (that is this very decision), and there is no in-repo program that needs it. Hole stays #[non_exhaustive], so if a concrete caller does appear the variant can still be added; deferring costs nothing that adding it now would save.

What would reopen this. Not a deck — no deck can carry the missing meaning. Only a library caller whose rule is genuinely too slow or too awkward through item 1: the point-per-cell composition is O(cells × holes), so a very large plane whose rule removes a large fraction of its cells is the case that would justify paying for Hole::Predicate. That is a measured need, not a speculative one, and it is what the #[non_exhaustive] marker is held in reserve for.

Decision: contact circle is not a documented shape (issue #109)

contact circle was carried in this table as a deferred shape — one whose argument list had still to be pinned from the public documentation — ever since the first plane-clause audit. Issue #109 went looking for that argument list. There is none, because there is no such clause.

The contact family is not described in the FastHenry user's guide at all: the guide's one mention of it is a note recommending contact equiv_rect for connections to a nonuniformly discretized plane, which points at a separate public supplement ("Nonuniformly Discretized Reference Planes in FastHenry 3.0", M. Kamon, 10 October 1996). That supplement is where every contact clause this table records comes from, and it names them all: the simple refinement utilities point, line, rect and decay_rect; the contact-area utility equiv_rect; the grouped connection and trace, written in terms of the simple ones; and the initial_grid / initial_mesh_grid pair that pre-divides the plane. No disc appears anywhere in it. circle is a hole shape (hole circle (x, y, z, r), from the user's guide's uniform-plane section), and holes and contacts do not share a shape vocabulary: the same supplement records that these routines do not support the hole utility at all.

So the earlier "argument list still to be pinned" wording had the situation backwards, and this row is now rejected the way hole user1…user7 are: not deferred work, but a name with no meaning to read. The reader keeps rejecting it by name, on the statement's own line, and the error says which family each name belongs to so a deck that meant hole circle is told exactly that.

The geometry was never the obstacle. Had the clause existed, the mapping would have been a one-liner on top of what contact decay_rect already does: refine the disc's bounding square. That is not an approximation of a disc on this engine — it is what a disc costs here. The plane mesh is a tensor product, so a refined x-band spans the plane in y and a y-band spans it in x; any refinement that covers a disc therefore has the disc's bounding-square bands, and their crossing is the square. (This is the same argument the diagonal contact line row above rests on.) Refining 4/π of the disc's area is the price, the same on any tensor-product mesh, and contact decay_rect (x, y, z, 2r, 2r, xcell, ycell, xmaxcell, ymaxcell) buys it today — widen each width by its own cell to keep the cells grazing the rim fine too. a_discs_bounding_square_is_what_refining_a_disc_costs in fasterhenry-cli/src/inp.rs asserts both halves of that: every cell inside the disc honours the requested size, and so does a bounding-square corner the disc misses.

What would reopen this. Public input-format documentation naming a contact circle utility and its value list. Then the row becomes a two-line parser arm over the mapping above, with the padding rule contact point already uses. Nothing about the plane model would change.

Decision: a diagonal contact trace is rejected natively, approximated under compat (issue #110, #157)

Native mode keeps the rejection described below: the public description does not determine the cell size, so the native reader will not guess. --fasthenry-compat (issue #157) instead accepts the clause and refines the trace's bounding box, padded by 3w/2 on every side, to cells (w/2)·s^min(|tan θ|, |cot θ|) on both axes (s = scale_factor, θ from p1 → p2 in the plane's frame), as one contact rect. Black-box runs against self-authored decks show this lands within a few percent of FastHenry's own staircase refinement (about 0.1-0.4% in L and 0.3-2% in R at s = 1), against about 5% without any refinement. The min() deliberately keeps 30° and 60° mirror-symmetric rather than copying FastHenry's behaviour past 45°, and the cell is capped at half the box's narrower width. A line-numbered warning says the refinement approximates FastHenry's staircase. The word "permanent" in this section's native rationale applies to native mode only.

A contact trace parallel to x or y is supported (its row above): the public memo Nonuniformly Discretized Reference Planes in FastHenry 3.0 (M. Kamon, 1996, section "Grouped contact utilities") writes that case out line by line, and says scale_factor does not affect it. For a trace at an angle θ to the x axis, the same section gives the cells under the trace as magnified by scale_factor — and states that magnification two ways that do not agree:

1. As a law: the cell sizes handed to contact line are multiplied by scale_factor^|tan θ|.
2. As prose: the magnification varies continuously from 1 to scale_factor as the angle goes from 0° to 45° or from 90° to 45°.

For θ between 0° and 45° the two agree. For θ between 45° and 90° they do not: |tan θ| exceeds 1 and grows without bound toward 90°, so the law magnifies the cells by more than scale_factor — without limit for a nearly-vertical trace — where the prose keeps the factor between 1 and scale_factor and returns it to 1 at 90°. A reader has to pick one, and the other is a different mesh. Even below 45° the memo leaves two further facts unstated that the cell size turns on:

• Where the side lines go. The axis-aligned expansion offsets its four side lines by ±w/2 and ±3w/2 across the trace; for a diagonal trace "across" could mean perpendicular to it or along one axis, and the memo shows neither.
• What cell the lines ask for along the trace. An axis-aligned trace asks for the trace's own length along it — no refinement there. A diagonal trace has no axis "along it"; the memo's 45° example gives the cell directly under the trace (scale_factor · trace_width / 2), which implies both axes get the magnified across-cell there, but says nothing of a 10° trace, where refining the whole bounding box to ~trace_width/2 in x is precisely what the utility exists to avoid.

So the cell size a diagonal contact trace asks for is not determined by the public description, and the clean-room rule (CONTRIBUTING.md) forbids settling it from anywhere else. The error therefore does not guess: it names contact line (x0, y0, z0, x1, y1, z1, xcell, ycell), with which a deck states the cell it wants outright (on this engine's tensor-product mesh a diagonal line refines its padded bounding box — see the contact line row — which is also what any reading of the diagonal contact trace would cost here).

What would reopen this. A public statement that settles the 45°–90° law and the diagonal side-line placement — not a deck, since a deck can only repeat the ambiguous clause.

Decision: (n1, n2) counts p1 → p2 then p2 → p3 (issue #113)

contact initial_grid and contact initial_mesh_grid were rejected by name until issue #113, for one reason: the pair of counts sets the plane's initial discretization, and reading them the wrong way round would silently mesh every non-square plane transposed — a deck that still solves, just at the wrong resolution. Issue #101 declined to guess, which is what the clean-room rule requires (CONTRIBUTING.md: no guessing an undocumented argument order or row/column convention).

The convention is documented, in the same supplement every other contact clause here is read from ("Nonuniformly Discretized Reference Planes in FastHenry 3.0", M. Kamon, 10 October 1996), read together with the FastHenry user's guide section on uniformly discretized planes. Three facts settle it, and this reader implements what they say:

1. The supplement states the equivalence outright. Its meshed-planes section says that the old-style uniform specification seg1=10 seg2=12 "could be replaced with file=NONE contact initial_grid (10,12)". So the first value is seg1 and the second seg2, position for position.
2. The user's guide defines that pair against the edges. seg1 is the number of segments along the edge from (x1,y1,z1) to (x2,y2,z2) and seg2 the number along the edge from (x2,y2,z2) to (x3,y3,z3) — with (seg1+1)·(seg2+1) nodes, so both are counts of cells, not of grid lines. Its own reference-plane figure labels the p1 → p2 edge seg1. The supplement adds that p1 is the origin of the plane coordinate system, p1 → p2 its x-direction and p2 → p3 its y-direction.
3. The supplement's own worked example only comes out square-celled read this way. Its run-time-discretization example declares a plane whose p1 → p2 edge is 8500 units long and whose p2 → p3 edge is 13500, and meshes it with contact initial_mesh_grid (34, 54). Taking the first count along p1 → p2 gives 8500/34 = 250 and 13500/54 = 250: square cells, exactly. Transposed it gives 8500/54 ≈ 157.4 by 13500/34 ≈ 397.1 — cells of two different, non-round sizes on a power plane whose designer plainly wanted a 250-unit grid.

The one sentence that reads the other way, and why it does not win. Between statements 1 and 2 above, the supplement glosses (10,12) as "10 is the number of rows and 12 the number of columns where a row has a co[n]stant y value". Rows of constant y stack along y, so read literally — with the plane's y being p2 → p3 — that sentence makes the first count the p2 → p3 one, contradicting the seg1=10 seg2=12 equivalence in the very next line of the same paragraph. Something in that sentence is loose, and the question is only which part.

It is resolved against the sentence, for three reasons. The equivalence (1) is explicit, positional and testable; the prose is a gloss on what the figure beside it looks like, and the figure carries no axes, so it fixes what "row" means on the page but not which plane edge the page's vertical is. The arithmetic (3) is independent of both and agrees with the equivalence to the last digit. And the failure modes are not symmetric: a reader that honours the equivalence reproduces the documented seg1/seg2 deck exactly, whereas one that honours the gloss silently disagrees with the supplement's own replacement rule. A deck author who wants no part of this argument can write seg1/seg2, which is unambiguous and which this reader has always taken.

The checkerboard. initial_mesh_grid marks "every cell that has an even value for both of its indices where the numbering is from the top left". The figure of a (7,6) meshed grid shows the holes at the 1-based even indices on both axes — second, fourth and sixth — so the numbering starts at 1, and a hole may touch the plane's edge when a count is even (the (7,6) figure's sixth column is holed) but never when it is odd. This reader numbers from the p1 corner along both axes, p1 being the origin of the plane coordinate system by (2) and the corner the user's guide's own plane figure draws at the top left. That choice is only observable when a count is even: for an odd count the even indices are symmetric about the plane's centre, so either end selects the same cells. the_meshed_initial_grid_* tests in fasterhenry-cli/src/inp.rs pin both parities, and the transposition guard (a 5 × 3 grid on a 10 × 6 plane, asserted equal to seg1=5 seg2=3 and unequal to seg1=3 seg2=5) is the_initial_grid_is_seg1_and_seg2_and_is_not_transposed.

What would reopen this. Public documentation that pins the row/column gloss the other way and explains away the seg1/seg2 equivalence and the example's cell arithmetic — all three, since each is independently sufficient here. Short of that, the mapping stands as implemented.

Decision: a contact clause's x…/y… pair is in plane coordinates (issue #118)

Until issue #118, this reader applied the contact clauses' per-axis lengths along global x and y. That is right for the plane every public example writes — one whose p1 → p2 edge runs along global x — and wrong for a plane whose first edge runs along global y, which this reader has always accepted (seg1_and_seg2_follow_the_edges_not_the_axes). On such a plane an anisotropic request was silently transposed: a deck that still solves, at the wrong resolution on each axis. The reader now maps the pair through the plane's own axes, so the five clauses that carry one agree with the rest of the plane model.

What the memo says. The same supplement every other contact clause here is read from ("Nonuniformly Discretized Reference Planes in FastHenry 3.0", M. Kamon, 10 October 1996) settles it in the clause where it matters most:

1. It defines the frame. p1 "specifies the origin of the plane coordinate system"; "the vector from p1 to p2 specifies the x-direction in the plane coordinate system. And similarly, the vector from p2 to p3 specifies the y-direction."
2. It states contact point's cell sizes in that frame, by name. Of contact point (1,0,0,0.1,0.2) it says the point "will be contained in a cell of dimensions no bigger than (0.1,0.2) where 0.1 is the width of the cell in the plane coordinate system's x-direction, and 0.2 is the width in the y-direction". This is explicit, not inferred.
3. The other four clauses are defined as point. The memo builds line from point ("walks along the line, calling the point utility for every cell it crosses"), rect from line ("calls the line utility for a set of parallel lines in the x-direction and another set in the y-direction"), decay_rect from rect ("calling the rect utility for gradually larger rectangles with gradually larger cell sizes"), and connection as exactly decay_rect (x,y,z,xwidth,ywidth,xwidth/ratio,ywidth/ratio,-1,-1) plus equiv_rect (x,y,z,xwidth,ywidth) over the same widths. A pair cannot change frames as it is passed down that chain, and connection's two halves would disagree with each other if equiv_rect's widths were global while decay_rect's were not.

4. It is the convention the plane already uses elsewhere. seg1/seg2 count along p1 → p2 and p2 → p3 (the user's guide), and contact initial_grid/initial_mesh_grid likewise (the decision above, issue

   #113). Reading the contact pairs globally would have made this one plane model use two different frames for its two kinds of per-axis value.

Coordinates are not relative. The other half of the question #118 asked: p1 being the frame's origin does not make the clauses' points, line ends or rectangle centres offsets from p1. The memo's own decay_rect example places contacts at (1,0,0) and (9,0,0) on a plane spanning y = -2 … 2 — y = 0 there is the plane's mid-height, the natural place for a two-port ground plane's contacts, and is not a plane-relative coordinate (relative to p1 = (0,-2,0) those contacts would sit on the plane's edge). Its equiv_rect example reads the same way. So every coordinate in a G statement's body stays an ordinary global deck coordinate, checked against the plane's footprint and slab; only the x…/y… lengths turn with the plane. p1 is used as an origin exactly where the memo needs one: for those two directions, and for the initial_mesh_grid cell numbering (above).

What this changes in practice. Nothing for a plane whose p1 → p2 edge runs along global x — the mapping is the identity there, which is why no existing test moved. For a plane whose first edge runs along global y, a clause's x… value is now measured along global y. contact trace is unaffected either way: it carries no x…/y… pair (one trace_width, and a direction taken from its own global ends) and its five-line expansion is symmetric in the two axes. The documented seven-value contact rect is not listed among the five above only because it is not a sixth clause: it is a contact decay_rect under another name (issue #95), so it turns with the plane exactly as decay_rect does, through the same code. This reader's own six-value corner-spelled contact rect genuinely is unaffected — its two corners are global coordinates, not a plane-relative length pair.

What would reopen this. Public documentation stating one of these five clauses' pairs in global x/y despite the plane coordinate system the same document defines — or a worked example that only comes out right read globally. Statement 2 above is a direct quotation about the clause the other four are built from, so short of that the mapping stands as implemented. contact_cell_sizes_follow_the_plane_axes_not_the_global_ones in fasterhenry-cli/src/inp.rs pins all five clauses (plus the documented contact rect, which is decay_rect under another name) against a rotated plane, a_square_contact_request_is_orientation_independent pins the isotropic no-op (contact trace included), and a_rotated_planes_decay_limit_error_names_the_decks_own_axis pins that the per-axis error messages name the axis the deck wrote.

Decision: a hole or contact rectangle off its plane is accepted with a warning (issue #105)

Every hole / contact clause's z has always been checked against the plane's slab, but until issue #105 a hole rect, hole point or hole circle whose xy lay wholly outside the plane's footprint was silently accepted and removed nothing — the mesh quietly differed from the one the deck asked for, typically because of a coordinate typo or a wrong .units scale. The rule now, per shape:

The warning is a diagnostic, not an error: a deck that parsed before still parses to the same mesh, and stdout is unchanged. It names the clause, the ground plane and the clause's physical line — the continuation (+) line it is written on, not the line its G statement starts on — and there is exactly one per offending clause, however many share a statement or a line. The command-line binary prints each on stderr as warning: line N: …; the library never prints: inp::parse_reporting / inp::parse_with_options_reporting and read_inputs_reporting / read_inputs_reporting_with return the warnings, while parse, parse_with_options, read_inputs and read_inputs_with keep their signatures and discard them (as run does run_reporting's).

Why a warning rather than an error: the clause is not malformed, and turning an accepted clause into a rejected one would break decks that parse today; a warning catches the typo without that cost. It is deliberately only about disjointness from the footprint. A clause inside the footprint that happens to change nothing — a circle too small to catch a cell centre, a hole inside another hole, a contact the background mesh already meets — does not warn: those are legitimate decks, and "warn whenever the final mesh is unchanged" would be different semantics.

Touching contacts (issue #134). A contact rect / contact decay_rect that meets the footprint only at its boundary — an exact touch, or an overlap no wider than fasterhenry::plane::contact_slack on some axis: the larger of a shape-relative 1e-9 × span and a coordinate-rounding 32 × f64::EPSILON × max(|lo|, |hi|) (scale-aware, not a fixed number of metres; the two are kept separate so a small plane translated far from the origin still keeps genuine partial overlaps) — carries no two-dimensional region, and is treated exactly like a disjoint one: dropped with one line-numbered warning (… only touches the boundary …) on its own clause line. Before this, a rounding-sized overlap (11e-3 - 1e-3 lands just below the plane edge) reached the mesher and failed assembly on line 0 with a zero-length segment. The library rejects the same overlaps as PlaneError::ContactOutsideFootprint; genuine partial overlaps still refine at the declared resolution. Holes keep their closed-boundary behaviour.

Two consequences worth stating:

• A wholly-disjoint contact rect / contact decay_rect used to be an error — not from this reader but from the plane library at assembly, reported on line 0 ("contact region … lies outside the plane footprint"). Such a region refines nothing, so it is now dropped with the warning instead, on its own line, consistent with the holes. No deck that parsed before changes meaning. A rectangle that only touches the footprint is dropped with its own warning too — see *Touching contacts (issue

  #134)* above.

• The stricter clauses stay errors. contact point, contact line and contact trace name a locus that must lie on the plane, and an off-plane end remains a line-numbered error; a contact equiv_rect (or the tie half of a contact connection) whose node is off the plane, or that covers no live cell, remains an error too. The .hole / .contact extension directives are unchanged.

fasterhenry-cli/src/inp.rs's tests disjoint_hole_point_warns_on_its_own_line, disjoint_hole_circle_warns_on_its_own_line, disjoint_hole_rect_warns_on_its_own_line, disjoint_contact_rects_warn_and_are_dropped, disjoint_contact_decay_rect_warns_and_is_dropped, one_warning_per_disjoint_clause_with_its_physical_line, shapes_meeting_the_footprint_do_not_warn, in_footprint_clauses_that_change_nothing_do_not_warn and stricter_off_plane_errors_are_unchanged pin the rule, and a_hole_off_its_plane_solves_with_a_line_numbered_warning in fasterhenry-cli/tests/cli.rs pins the command-line behaviour.

.couples

Directives outside the deck subset

Anything else — including directives that configure FastCap's multipole solver (this engine does not use that algorithm, so such parameters have no equivalent here) — is rejected with a line-numbered error naming the directive ('.<name>' is not in the deck subset) rather than silently ignored. No such directive surfaced during this audit that is not already tracked by a sibling issue in the epic (#71, #80); nothing new is filed as a result of this table beyond what is listed below.

Follow-ups filed

• Issue #83: reading genuine third-party decks whose first line is prose (not .title) — resolved by the opt-in --fasthenry-compat mode; see "Deck framing" above.
• Issue #95: contact rect's argument list, which this reader spelled as two opposite corners where the documented form is a centre, full widths and cell sizes (found while implementing contact decay_rect for #80). Since implemented: the reader now takes both, told apart by value count — seven values are the documented centre/widths/cell form (exactly contact decay_rect with no outward limits), six keep the corner meaning as an extension, and any other count is a line-numbered error naming both. See "Decision: contact rect reads both spellings, told apart by value count" above for why accepting both beat migrating to the documented form alone or documenting the divergence permanently.
• Issues #99, #100, #101: the hole and contact shapes #80 and #98 left rejected, split by the model change each needs — user-defined holes, the contact refinement primitives, and the named-equipotential / initial-grid contact forms. (Issue #98, non-rectangular holes, has since been implemented — see its own hole point (x, y, z) / hole circle (x, y, z, r) row above. Issue #99 has since been decided rather than implemented: hole user1…user7 are permanently rejected, for the reasons in "Decision: hole user1…user7 are rejected permanently" above. Issue #100 has since implemented contact point and contact line — see their row above — and moved contact circle and contact trace to issues #109 and #110. Issue #109 has since been decided rather than implemented, like #99: contact circle is not a documented shape at all, so it is permanently rejected — see "Decision: contact circle is not a documented shape" above. Issue #110 has since implemented contact trace along x or y and decided the diagonal case as a permanent rejection — see its rows above and "Decision: a diagonal contact trace is rejected". Issue #101 has since been implemented for contact equiv_rect and contact connection — their own rows above — and filed #113 for the two initial-grid forms it deliberately left rejected.)
• Issue #113: the row/column convention contact initial_grid and contact initial_mesh_grid turn on, which the public description this audit is written from did not settle for #101. Since implemented: the convention was read out of that description after all — see "Decision: (n1, n2) counts p1 → p2 then p2 → p3" above for the evidence and for the one sentence of it that reads the other way — so both clauses now have supported rows in the table.
• Issue #122: file= on a plane statement, which the nonuniform-plane description defines as an input (the discretization hierarchy file, NONE for none) rather than the output option this reader's rejection message used to call it — and whose file=NONE form is what the public contact initial_grid example pairs the clause with. Found while implementing #113. Since implemented: file=NONE is accepted as the no-op it is, since "no hierarchy file, discretize from the statement's own clauses" is the only case this reader has, so the documented file=NONE contact initial_grid (10,12) line now reads as written; a named hierarchy file is still rejected, now as the unread input it is. See the two file= rows above.