Validate against EMEFieldMonitor with EMELengthSweep

[caseyflex]

docs PR: flexcompute/tidy3d-notebooks#340

EMEFieldMonitor gives misleading / incorrect results in EME simulations with EMELengthSweep. This is because while the coefficients and smatrix are swept correctly, the field data is still calculated on the original simulation geometry and grid.

This PR just validates against the combination.

Greptile Summary

This PR addresses a technical limitation in EME (Eigenmode Expansion) simulations by adding validation to prevent the problematic combination of EMEFieldMonitor with EMELengthSweep. The core issue is that during length sweeps, while the EME coefficients and S-matrix are correctly recalculated for each swept geometry, the EMEFieldMonitor field data remains calculated on the original simulation geometry and grid, creating a fundamental mismatch that leads to misleading or incorrect field results.

The solution implements validation in the _validate_sweep_spec method of the EME simulation class that checks all monitors and raises a SetupError if an EMEFieldMonitor is detected when the sweep specification is an EMELengthSweep. This validation follows the existing pattern used for other incompatible monitor/sweep combinations like EMEPeriodicitySweep and EMEFreqSweep.

The changes also include comprehensive test updates to ensure the validation works correctly and that existing length sweep tests continue to function by filtering out EMEFieldMonitor instances from monitor lists when testing sweep functionality. A changelog entry documents this as a fix that disallows the problematic combination.

This approach prioritizes user safety by preventing incorrect results rather than attempting to fix the underlying architectural complexity of making field monitors work properly with geometry changes during sweeps.

Confidence score: 5/5

• This PR is extremely safe to merge as it only adds validation to prevent a known problematic configuration that produces incorrect results.
• The validation is straightforward, follows existing patterns in the codebase, and includes comprehensive test coverage to ensure it works as expected.
• All files have clear, focused changes with no complex logic or potential edge cases that could introduce bugs.

[greptile-apps]

_{3 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[caseyflex]

@FilipeFcp we will also need to update this notebook:
https://www.flexcompute.com/tidy3d/examples/notebooks/EMESolver/

How should we handle that? It is inconvenient to have to run a separate simulation just to visualize the field. I guess we could just get rid of the field visualization in that example.

[FilipeFcp]

Well, we do a separate run in the EME part of this notebook.

But I think we can just remove the visualization for the taper. It is not very informative, and we already presented it in the previous example.

[caseyflex]

Well, we do a separate run in the EME part of this notebook.

But I think we can just remove the visualization for the taper. It is not very informative, and we already presented it in the previous example.

Great, sounds good. I'll make a PR to remove it from that notebook.

[greptile-apps]

_{No files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[github-actions]

Diff Coverage

Diff: origin/develop...HEAD, staged and unstaged changes

• tidy3d/components/eme/simulation.py (100%)

Summary

• Total: 3 lines
• Missing: 0 lines
• Coverage: 100%

[caseyflex]

docs PR is merged, @yaugenst-flex let me know when you want me to merge this

[yaugenst-flex]

Thanks @caseyflex this looks good to go, only a minor comment. Sorry this slipped through the cracks!

[yaugenst-flex]

For GUI it's nice to also have the monitor name, we recently switched to including that for a lot of similar validator errors. So let's do Monitor {monitor.name} at 'monitors[{i}]' is here.