Validation
Use this page to select a documented configuration and the evidence required for an rfx result. Begin with the Recommended Configuration and then check Support Boundaries for the exact mesh, source, port, calculator, and observable restrictions.
Configuration and required validation
Section titled “Configuration and required validation”| Configuration | Required validation |
|---|---|
| uniform Cartesian Yee RF/FDTD workflows | use the documented boundaries, sources, observables, convergence checks, and analytic or independent reference |
| rectangular waveguide S-matrices | use compute_waveguide_s_matrix(...) only for the documented guide geometry, modes, frequency range, normalization, reference planes, and placement |
| lumped, wire, microstrip-line, and coaxial-line calculations | use the calculator for that port family and remain within its stated limits |
| differentiable design loops | treat the optimization quantity as a proxy and validate the final RF observable separately |
| other repository code | treat RF accuracy as unvalidated unless a public guide and support entry define the configuration and evidence |
Runnable examples
Section titled “Runnable examples”validation/crossval/05_patch_antenna.py— patch-antenna cross-checkvalidation/crossval/11_waveguide_port_wr90.py— rectangular waveguide-port workflowexamples/inverse_design/multilayer_ar_coating.py— inverse-design example; validate the optimized result independently
Evidence, artifacts, and reports
Section titled “Evidence, artifacts, and reports”Plots, Touchstone files, HDF5 snapshots, CSV tables, and report bundles are useful review artifacts. They become validation evidence only when paired with a documented analytic result, dump replay, external-solver comparison, convergence study, or benchmark acceptance criterion.