Cross-Validation and Accuracy
This page gives the short public version of rfx validation status. For the per-case table, see the Benchmark Table.
Recommended default lane
Section titled “Recommended default lane”The most mature public path is the uniform Cartesian Yee RF/FDTD lane:
- cavity and waveguide-style RF problems
- patch-style resonance workflows
- probes and Harminv resonance extraction
- selected port and S-parameter workflows
- benchmarked far-field workflows
Use this lane when you want the safest starting point.
Bounded envelopes
Section titled “Bounded envelopes”The following workflows are public only within their documented envelope:
- rectangular waveguide S-matrices via
compute_waveguide_s_matrix(...) - specialized microstrip-line S-matrices via
compute_msl_s_matrix(...) - lumped/wire S-parameters via the matching
add_port(...)calculator - one-port coaxial transmission-line reflection via
compute_coaxial_line_reflection(...) - differentiable design loops that use proxy objectives and then validate the final observable through the relevant lane
These features may have examples and tests, but their support boundaries are narrower than the default lane and must be described with their current evidence envelope.
Recommended public examples
Section titled “Recommended public examples”| Example | Role |
|---|---|
examples/crossval/05_patch_antenna.py | current patch cross-check and practical antenna reference |
examples/crossval/11_waveguide_port_wr90.py | rectangular waveguide-port reference workflow |
examples/inverse_design/multilayer_ar_coating.py | inverse-design demo with a conservative public scope |
Practical takeaway
Section titled “Practical takeaway”Lead public messaging with the recommended uniform Yee RF lane. Mention bounded port-family envelopes only when the user specifically needs them, and keep those descriptions scoped to current examples, evidence, and limitations.