Results and Observables
Result is the object returned by Simulation.run().
Primary fields
Section titled “Primary fields”| Field | Meaning | Public use |
|---|---|---|
state | final solver state / checkpoint payload | inspection, checkpoint export, and debugging; no high-level resume API accepts it as an initial state |
time_series | recorded probe values over time | ringdown, transient response, Harminv |
s_params | lumped/wire port S-matrix | matching, filters, de-embedding |
freqs | frequency axis paired with Result.s_params | lumped/wire S-parameter output; DFT-plane and flux-monitor objects carry their own frequency axes |
ntff_data | near-to-far-field accumulation | radiation patterns where documented |
dft_planes | frequency-domain plane observables | slices and field maps |
flux_monitors | plane flux accumulations | transmission / reflection analysis |
waveguide_sparams | per-port waveguide diagnostics | waveguide workflows |
snapshots | saved field snapshots | visualization and post-processing |
grid | mesh metadata | reproducibility checks |
dt | timestep | time-axis conversion |
S-parameter result schemas
Section titled “S-parameter result schemas”| Calculator | Result object | Public status |
|---|---|---|
run(compute_s_params=True) with lumped/wire add_port(...) | Result.s_params, Result.freqs | documented path for the matching port family |
forward(port_s11_freqs=...) with lumped/wire add_port(...) | ForwardResult.s_params, ForwardResult.freqs | differentiable S11 vectors, not a full multi-port matrix |
compute_msl_s_matrix(...) | MSLSMatrixResult with .S, .freqs, .Z0, .beta, .port_names, .reliable, .settling_db, .S_raw, .passivity_correction | specialized microstrip-line calculation. .S is passivity-enforced by default (` |
compute_waveguide_s_matrix(...) | WaveguideSMatrixResult | rectangular waveguide workflow |
compute_coaxial_line_reflection(...) | CoaxialLineReflectionResult | reflection with float32 precision, a nonperiodic 3D second-order uniform Yee grid, CPML on all six boundary faces with positive thickness on both z faces, cpml_axes="z", and exactly one face="top" coaxial port; see Sources and Ports for the self-contained model limits |
run(...) with a single waveguide port | Result.waveguide_sparams[name] | diagnostic per-port output |
Sources, TFSF, probes, DFT planes, and flux monitors do not automatically define a high-level S-matrix workflow. Coaxial reports should use the documented line-reflection method.
Observable builders that feed Result
Section titled “Observable builders that feed Result”| Builder | Result field | Typical use |
|---|---|---|
add_probe(...) / add_vector_probe(...) | time_series | transient response, ringdown, local field traces |
add_dft_plane_probe(...) | dft_planes | frequency-domain field slices |
add_flux_monitor(...) | flux_monitors | reflection / transmission bookkeeping |
add_ntff_box(...) | ntff_data, ntff_box | far-field accumulation |
Finite-size flux monitors use the same per-cell Poynting integrand as full-plane monitors. When both are summed over the same index window, they agree to machine precision; differences from size=None full-plane monitors are coverage choices, not a separate stability model.
Resonance extraction
Section titled “Resonance extraction”Result.find_resonances() runs Harminv-style mode extraction on a probe time series.
result = sim.run(n_steps=8000)modes = result.find_resonances(freq_range=(1.5e9, 3.5e9))Use this on a clean probe signal when you want a resonance estimate that is less dependent on port calibration than S-parameters.
Port-observable helpers
Section titled “Port-observable helpers”rfx.validation provides helper functions for checking S-matrix-like arrays for shape, finite values, frequency metadata, port names, and caller-selected passivity / reciprocity limits.
from rfx import validate_port_smatrix, assert_port_smatrix_valid
report = validate_port_smatrix(result, check_passivity=True, passivity_tol=0.02)print(report.summary())These helpers are useful for regression checks. They do not turn an undocumented workflow into the recommended default path.
During normal Python execution outside JAX tracing, some calculation paths emit warnings without changing the arrays. Coverage is deliberately narrow:
- the generic
run()warning and uniform single-deviceforward()warning inspecttime_seriesand lumped/wires_params, not state, NTFF, DFT-plane, or flux arrays; non-uniform and distributedforward()paths do not invoke this guard; - lumped/wire
run()and uniform single-deviceforward()check individual entries for non-finite values or|S| > 1.1, but do not test total outgoing column power; - MSL and waveguide full-matrix calculators apply per-entry and column-power checks with calculator-specific tolerances;
compute_coaxial_line_reflection()requires float32 precision, a nonperiodic 3D second-order uniform Yee grid, CPML on all six boundary faces with positive thickness on both z faces,cpml_axes="z", and exactly oneface="top"coaxial port. It builds its own line, source, probes, and termination and rejects unsupported registered objects. It returnsstatus, fit/recurrence residuals, ands11, but does not run the shared passivity guard. See Sources and Ports before configuring this method.
The ring-down advisory likewise requires a probe time series and is not a direct NTFF or DFT convergence test. Inspect unguarded arrays explicitly. The absence of a warning is not a passivity, convergence, or accuracy result.
For MSL results, reliable[p, k] = False excludes the whole frequency slice
S[:, :, k] from physical interpretation — not just the driven-port column —
because S is solved jointly across drives (S = B·A⁻¹, #507); the mask covers
every driven/port record the solve consumes (#522). A True entry is not an
accuracy guarantee. See
Probes and S-Parameters for the
threshold and filtering example.
Validated observables
Section titled “Validated observables”For public docs, describe observables in simple terms:
time_seriesand Harminv are the recommended resonance path.- lumped/wire, MSL, waveguide, and coaxial-line S-parameter/reflection workflows each have their own calculator and stated limits.
- NTFF/far-field outputs should be used where the relevant guide documents the workflow.
- Other fields are useful analysis outputs; apply the documented support status for the calculation that produced them.