Skip to content

Anisotropic EME bends#462

Open
FilipeFcp wants to merge 4 commits into
developfrom
filipe/AnisotropicEME
Open

Anisotropic EME bends#462
FilipeFcp wants to merge 4 commits into
developfrom
filipe/AnisotropicEME

Conversation

@FilipeFcp

Copy link
Copy Markdown
Contributor

Hi guys,

These are the results and a sketch of an example notebook. The final formatting and text were mainly done with Claude Code, with some guidance. I think it looks reasonable.

I think we should wait for the next API release before publishing this right? So I will remove the solver version part latter.

@caseyflex

Copy link
Copy Markdown
Contributor

This is great! I love the convergence plot. Thanks for finding the bug and helping address it.

  • We should note at the top that the entire notebook is a bit expensive to run
  • I updated the solver and added a flag EMEModeSpec.bend_medium_frame which controls whether the rotation is applied to the material tensor. The default value will capture the behavior from this notebook which is a change in the EME solver behavior and matches FDTD. However the user has the option to change it to co_rotating if they are imagining bending a fiber for example, and they want the tensor to already be defined in the co-rotating frame. Maybe you could take a look at this flag and the docstrings, and echo some of that in this notebook, making that flag explicit too?

@caseyflex

Copy link
Copy Markdown
Contributor

I wonder if there is a better way to use mode sorting / filtering to find the well-guided quasi-TE mode, which could be cleaner than just taking the max transmission

@caseyflex

Copy link
Copy Markdown
Contributor

Actually it would be excellent to explicitly show the permittivity tensor somewhere along the bend for both cases of bend_medium_frame. So we can have a very explicit discussion of the two use cases

@momchil-flex

Copy link
Copy Markdown
Collaborator

Really nice verification thanks @FilipeFcp ! I don't have much to say beyond Casey's comments. Maybe no need to run 20 cells as the convergence seems pretty clear already beyond like 4.

Actually it would be excellent to explicitly show the permittivity tensor somewhere along the bend for both cases of bend_medium_frame. So we can have a very explicit discussion of the two use cases

Is PermittivityMonitor supported in some way in EME? But generally yeah I think this is a good idea, maybe take a 3-cell simulation and plot the diagonal components of the permittivity at the 3 locations. Or even plot eps_xx, eps_xy, eps_xz (first row of the tensor) to show how it becomes tensorial in the "lab" frame and just stays the same in the "co-rotating" frame.

@caseyflex

Copy link
Copy Markdown
Contributor

Permittivitymonitor is fully supported in eme . Or you can probably use sim.epsilon, and you even get subpixel if tidy3d-extras is installed!

@github-actions

Copy link
Copy Markdown
Contributor

Spell Check Report

AnisotropicBendsEME.ipynb:

Cell 3, Line 1: 'Bent-Waveguide'
  > ## Physics Background: Why Anisotropy Complicates Bent-Waveguide EME
Cell 3, Line 5: 'z-cut'
  > For a z-cut LiNbO₃ slab the permittivity tensor in the lab frame is diagonal:
Cell 3, Line 13: 'cross-coupling'
  > In a **straight** waveguide propagating along x the tensor is constant — modes are pure TE or TM and propagate without cross-coupling.
Cell 3, Line 25: 'back-reflections'
  > EME divides the waveguide into $N$ cells and matches eigenmodes at each cell boundary. At every interface the two adjacent mode bases are slightly misaligned due to the incremental tensor rotation — generating partial **back-reflections** and **mode conversion**.
Cell 3, Line 29: 'inter-cell'
  > | **1** | Entire 180° bend is one uniform section. No inter-cell interfaces → **no reflections from tensor rotation** → transmission is overestimated. |
Cell 3, Line 30: 'back-reflection'
  > | **few** | Tensor rotation is approximated as a staircase; dominant back-reflection is captured. |
Cell 3, Line 33: 'polarization-state'
  > The loss mechanism is not geometric bending loss (negligible at $r = 5$ µm for this waveguide) but **polarization-state evolution** driven by the rotating anisotropy.
Cell 4, Line 15: 'z-cut'
  > LiNbO3 = td.material_library["LiNbO3"]["Zelmon1997"](1)  # (1) → z-cut orientation
Cell 6, Line 21: 'well-confined'
  > # Sort modes by ascending k_eff: the well-confined guided mode has the
Cell 10, Line 2: 'well-confined'
  > # the mode solver returns modes ordered by ascending loss — so the well-confined
Cell 14, Line 13: 'back-scattering'
  > - **$N = 1$**: No interfaces → no back-scattering from tensor rotation → **overestimated transmission**.
Cell 17, Line 1: 'EMEModeSpec'
  > # Mode selection: with sort_spec(sort_key="k_eff") on the EMEModeSpec,
Cell 19, Line 15: 'straight-waveguide'
  > With a single EME cell the solver computes one set of curved eigenmodes for the entire 180° arc, assuming a fixed tensor orientation. At the ports, these modes are matched to straight-waveguide modes. With no internal interfaces, the system behaves close to a lossless propagator.
Cell 19, Line 17: 'reprojected'
  > In reality, the eigenmodes evolve continuously as the tensor rotates. Splitting the arc into $N$ cells approximates this as discrete steps. At each step, modes are reprojected onto a new basis, introducing reflections and mode mismatch. Increasing $N$ improves this approximation.

Checked 1 notebook(s). Found spelling errors in 1 file(s).
Generated by GitHub Action run: https://github.com/flexcompute/tidy3d-notebooks/actions/runs/24841187116

@FilipeFcp

Copy link
Copy Markdown
Contributor Author

@caseyflex @momchil-flex

This is the results running with the new version.
I also sorted the modes for the smallest k_eff, and it seems to work well to pick the correct one.

@caseyflex caseyflex left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks pretty good, a few more suggestions

  • it says "store_coeffs=True, # needed to access the full S-matrix". I don't think that is true, the full s-matrix should always be stored.
  • sorting by keff is not something I'm super confident in. You already do a standalone mode solve first to show the guided mode, which is good. Maybe we can show some metrics for all the modes, like the fill_fraction_box, te_fraction, keff, neff, etc. So that we are confident in the filtering approach

@FilipeFcp

Copy link
Copy Markdown
Contributor Author

Thanks Casey, these are good points.

Is the fill factor from this new release? I didn’t find it in the documentation when I first created this notebook. It’s very handy.

@caseyflex

Copy link
Copy Markdown
Contributor

Thanks Casey, these are good points.

Is the fill factor from this new release? I didn’t find it in the documentation when I first created this notebook. It’s very handy.

yes it's very handy! It's been around for a while. the latest version of the docs is actually broken / pointing at an older version -- @daquinteroflex is aware of this and working on it I think

https://docs.flexcompute.com/projects/tidy3d/en/v2.11.0/api/_autosummary/tidy3d.ModeSortSpec.html#tidy3d.ModeSortSpec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants