Support Boundaries
This page summarizes the public support scope for user-facing rfx workflows.
Status legend
Section titled “Status legend”| Status | Meaning |
|---|---|
| recommended default | best place to start for public examples and ordinary RF workflows |
| bounded envelope | usable only within the stated geometry, mesh, frequency, or calculator limits |
| outside documented scope | available code may exist, but public claims require a guide and support-matrix entry |
| unsupported | should fail clearly rather than degrade silently |
Recommended default lane
Section titled “Recommended default lane”| Dimension | Recommended subset |
|---|---|
| grid / runner | uniform Cartesian Yee |
| boundaries | PEC, CPML, bounded UPML |
| sources | point/current, lumped port, wire port, specialized microstrip-line port, rectangular waveguide port |
| observables | probes, flux, Harminv resonance, selected S-parameter workflows, documented far-field workflows |
| materials | isotropic linear, conductive, and documented dispersive subsets |
| workflows | cavity, waveguide, patch-style resonance, simple scattering, de-embedding, selected differentiable proxy objectives |
S-parameter calculation surfaces
Section titled “S-parameter calculation surfaces”| Primitive | Calculation API | Public status |
|---|---|---|
lumped/wire add_port(...) | run(compute_s_params=True) | documented calculator for the matching port family; validation scope follows the support envelope |
lumped/wire add_port(...) | forward(port_s11_freqs=...) | differentiable S11 vectors on the uniform single-device path |
add_msl_port(...) | compute_msl_s_matrix() | specialized microstrip-line workflow |
add_waveguide_port(...) | compute_waveguide_s_matrix() | rectangular waveguide workflow; use the guide-recommended normalization mode |
add_coaxial_port(...) | compute_coaxial_line_reflection(...) | one-port coaxial transmission-line reflection envelope only; not a general multi-port coaxial S-matrix workflow |
| sources, TFSF, probes, flux monitors | not port calculators | field/flux/time observables |
Repository code outside the public support scope
Section titled “Repository code outside the public support scope”Some repository code exists for compatibility, testing, or qualification. It should not be used for public claims unless the workflow is documented in a public guide and has a matching support-matrix entry.
Unsupported combinations
Section titled “Unsupported combinations”Unsupported combinations should fail clearly. Common examples include using a calculator with the wrong port family, mixing non-default mesh profiles with S-parameter calculators that only support the uniform lane, or treating field probes and flux monitors as impedance-defined ports.
Practical rule
Section titled “Practical rule”If the workflow is not in the recommended default lane or a bounded envelope above, present it as outside the documented public support scope.
Artifact and report exports
Section titled “Artifact and report exports”Touchstone files, plots, HDF5 snapshots, CSV sweep tables, and JSON manifests are interoperability or reporting artifacts. They preserve what a run produced, but they do not by themselves promote a workflow to supported status. Public reports should carry the originating port/source family, support status, command, git SHA, and metric used for pass/fail.