# Support Boundaries

Channel: release; package: 1.8.0; source: 7d1e97331656dd74ad0f5471653ac0c5effdff70

Page: https://remilab.ai/rfx/versions/v1.8.0/api/support-boundaries/
Source: https://github.com/bk-squared/rfx/blob/7d1e97331656dd74ad0f5471653ac0c5effdff70/docs/public/api/support-boundaries.mdx

This page summarizes the public support scope for user-facing rfx workflows.

## Status legend

| Status | Meaning |
|---|---|
| **recommended default** | best place to start for public examples and ordinary RF workflows |
| **limited** | 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 configuration

| Dimension | Recommended subset |
|---|---|
| grid / runner | uniform Cartesian Yee |
| precision | `float32` default; `float64` and `mixed` are uniform-single-device only, with the documented CPML residual-floor caveat for `mixed` |
| boundaries | PEC, CPML, and UPML within its documented limits |
| 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, documented dispersive subsets, and patterned one-cell surface-impedance sheets only within their stated lane restrictions |
| workflows | cavity, waveguide, patch-style resonance, simple scattering, de-embedding, selected differentiable proxy objectives |
| non-uniform profiles | feature-specific limited or experimental scope; use the [Non-Uniform Mesh guide](https://remilab.ai/rfx/versions/v1.8.0/guide/nonuniform-mesh/) for axis and calculator restrictions |

## S-parameter APIs

| Primitive | Calculation API | Public status |
|---|---|---|
| lumped/wire `add_port(...)` | `run(compute_s_params=True)` | documented calculator for the matching port family; use only within its stated validation limits |
| lumped/wire `add_port(...)` | `forward(port_s11_freqs=...)` | differentiable S11 vectors on the uniform single-device configuration |
| `add_msl_port(...)` | `compute_msl_s_matrix()` | specialized microstrip-line workflow; Laplace/quasi-TEM directions `+x`, `-x`, `+y`, and `-y`; eigenmode remains x-only and outside the public support envelope |
| `add_waveguide_port(...)` | `compute_waveguide_s_matrix()` | rectangular waveguide workflow, **limited**. Differentiation through `eps_override`/`sigma_override` runs on `normalize=False` and `normalize="flux"` only; `normalize=True` is host-assembled and raises `NotImplementedError` for a traced override. Multimode (`n_modes>1`) is host-assembled and outside the differentiable chain. S is a modal voltage-wave ratio referenced to each port's own discrete modal impedance, so it is a power-wave S only when all ports share one cross-section. Magnitude evidence for uniform single-mode guides is broader than phase, junction, and nonuniform evidence, Chain battery: chain-closed (v1.8) for uniform single-mode S on the `normalize=False` and `normalize="flux"` lanes. Contract criteria 1 and 3(a) are read under `JAX_ENABLE_X64` on the flux lane, so a float32 gradient pipeline there is outside the declaration. Chain-closed is not supported — this row stays **limited**. The full row, including the battery verdict and the `JAX_ENABLE_X64` dtype rule, is in `docs/guides/support_matrix.md` (Rectangular-waveguide S-matrix) and `docs/guides/sparameter_support_matrix.md`. |
| `add_coaxial_port(...)` | `compute_coaxial_line_reflection(...)` | `precision="float32"`; nonperiodic 3D second-order uniform Yee grid; CPML on all six boundary faces with positive thickness on both z faces; `cpml_axes="z"`; exactly one `face="top"` coaxial port; see [Sources and Ports](https://remilab.ai/rfx/versions/v1.8.0/api/sources-ports/) for rejected registrations and accepted arguments |
| sources, TFSF, probes, flux monitors | not port calculators | field/flux/time observables |

## Repository code outside the public support scope

Some repository code exists only for backward compatibility or internal testing. Treat it as supported public API only when a public guide documents the workflow and the support matrix lists it.

## Studio, CLI, and MCP results

These tools record and reproduce local runs. A valid spec, completed run,
passing replay, or comparison report does not validate electromagnetic
accuracy. Apply the documented limits for the selected mesh, source, port, and
observable, and perform the required convergence or reference comparison.
Studio plots only the result types listed in
[Studio, CLI, and MCP Experiments](https://remilab.ai/rfx/versions/v1.8.0/guide/studio-experiments/); other
artifacts may still be available through the CLI, API, MCP, or replay bundle.
MCP operations that change data or start costly work require server-side
approval.

## Unsupported combinations

Unsupported means the run or the request must fail rather than return a number.
These four are named in the nonuniform-mesh classification table of
`docs/guides/support_matrix.md`:

| Combination | Required failure |
|---|---|
| Periodic/Floquet port + nonuniform mesh | "Preflight or the calculation must fail." |
| `boundary="upml"` + nonuniform mesh | "The run must fail. The non-uniform runner has no UPML implementation — its absorber dispatch keys on the CPML layer count and never reads the boundary type — so this combination was accepted and silently ran CPML while `sim._boundary` still reported `upml` (issue #680). Use `boundary='cpml'` on a graded mesh." |
| Lumped-port S-parameters + nonuniform mesh | "The S-parameter request must fail." |
| Coaxial port + nonuniform mesh | "The request must fail." |

Calling a calculator with the wrong port family, or reading a field probe or
flux monitor as an impedance-defined port, is unsupported for the same reason:
neither has a port impedance or an S-matrix reference plane.

## Practical rule

If a workflow is not in the recommended configuration or a stated limited
configuration in these tables, the linked feature guide, or the support
matrices, present it as outside the documented public support scope. A
successful preflight or completed run does not expand that scope.

## Artifact and report exports

Touchstone files, plots, HDF5 snapshots, CSV sweep tables, and JSON manifests
preserve what a run produced, but they do not establish that the underlying
calculation is supported or accurate. Public reports should include the
port/source family, support status, command, git SHA, and pass/fail metric.