Inverse-designed crossing from a four-port S-matrix target

validated · 2026-08-28

invdesresolution 0.2invdesreal_world_devicetidy3d_goldensmatrixcrossing

This case checks optimization performance: the best objective reached, not geometry identity or convergence speed. The originating Tidy3D example is Autograd27Smatrix.ipynb, pinned at commit c37c785d52e9.

Open the complete executed tutorial →

Parameters → exact geometry → voxelized material → local FDTDX run → simulated field → quantitative analysis. Every code cell and retained output is visible, and the .ipynb source is downloadable.

S-matrix crossing: four-port inverse design

This page is the compact benchmark record. The linked notebook is the primary scientific documentation and contains the actual simulation evidence.

What is exercised

The first 25 updates use the published fixed-beta Adam setup. A generic fixed-beta, decayed-learning-rate continuation may use the remaining 3x iteration cap. Acceptance is based only on a fresh simulation of the fixed 0.5-threshold, fully binary material map; continuous performance is diagnostic. An independent Tidy3D forward solve of that artifact gives FOM 0.91920 versus 0.96945 locally and 0.98044 published, so the final design is within 6.2% of the published result under the reference solver. It passes the user’s 10% trust check but reaches only 93.75% of published performance, below this case’s stricter 95% optimizer-parity gate.

This case runs at a 0.20 resolution factor. Its declared tolerance scaling is applied by the comparator.

Reconstruction choices

This is a performance-equivalence reconstruction of the official notebook, not a pixel copy. The design is optimized by differentiating a real FDTDX time-domain solve. No final Tidy3D material pixels are imported. The recorded best result uses a 162 × 162 × 1 Yee grid, 31470 time steps per solve, and 75 local updates, versus 25 updates in the published Tidy3D run.

The acceptance target is 95% of the published best FOM. Iteration count may be up to three times the Tidy3D count, because device performance—not matching a particular topology or optimizer speed—is the scientific claim. Incident power is calibrated independently, port power is checked for passivity, and wavelength-routing cases share one physical filtering/projection policy.

Recorded result

Metric	Observed / error	Reference / limit	Error	Effective budget	Result
best_fom_parity	0.969443	0.931416	-0.0380267	—	PASS
optimizer_improvement	0.292162	1.000e-04	-0.292062	—	PASS
passive_power_excess	0	0	0	0.05	PASS
final_binary_fraction	1	1	0	—	PASS

The table is rendered from progress.json; it is not a hand-written success claim. For metrics that report an error directly, the “observed” column repeats that error and the reference column is the acceptance threshold.

Reproduce

uv run fdtdx-bench run --case invdes_smatrix_crossing

Implementation and provenance: benchmarks/cases/invdes_smatrix_crossing/case.yaml, benchmarks/cases/invdes_smatrix_crossing/run.py, benchmarks/goldens/invdes_smatrix_crossing.npz.

Return to the example atlas