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

<span class="validation-badge">validated · 2026-08-28</span>

<div class="case-meta"><span>invdes</span><span>resolution 0.2</span><span>invdes</span><span>real_world_device</span><span>tidy3d_golden</span><span>smatrix</span><span>crossing</span></div>

This case checks optimization performance: the best objective reached, not geometry identity or convergence speed. The originating Tidy3D example is [`Autograd27Smatrix.ipynb`](https://github.com/flexcompute/tidy3d-notebooks/blob/c37c785d52e9258c9d048a781524b8e8d7c758ca/Autograd27Smatrix.ipynb), pinned at commit `c37c785d52e9`.

::::{grid} 1

:::{grid-item-card} Open the complete executed tutorial →
:link: ../notebooks/smatrix_crossing
:link-type: doc
:class-card: device-ladder-card

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.
:::

::::

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 | — | <span class="metric-pass">PASS</span> |
| `optimizer_improvement` | 0.292162 | 1.000e-04 | -0.292062 | — | <span class="metric-pass">PASS</span> |
| `passive_power_excess` | 0 | 0 | 0 | 0.05 | <span class="metric-pass">PASS</span> |
| `final_binary_fraction` | 1 | 1 | 0 | — | <span class="metric-pass">PASS</span> |

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

```bash
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](../index.md)