Multimode Gmeep Simulation

[joelslaby]

Is your feature request related to a problem? Please describe.
Running simulations in meep through the gmeep plugin api is currently limited to only launching the fundamental TE0 mode into the waveguide. Some devices support higher order modes (such as modal demux) and require the ability to simulate other modes. The current snp format in gdsfactory currently labels the port and the mode (o1@0), but at least for gmeep, that mode value is never used.

Related to tidy3d, it's not immediately clear whether this api is already supported in the plugin. If it is not, then that could also be a useful addition to simulate multimode structures with tidy3d.

Describe the solution you'd like
I have an initial pull request ready that implements the following (in the gmeep plugin):

• specify which sources to use and which mode(s) to launch from that source
• specify which modes to measure on all the output ports
• stores the data in the appropriate key in the snp dictionary

The preliminary pull request adopted much of the surrounding code structure to get the feature out, but future edits can reformat and clean things up a bit.

Additional features still need to implement:

• specify the type of mode (TE/TM) with eigparity
• validate chosen mode by plotting modes (I believe this functionality exists in tidy3d, but can easily be extended to gmeep as well)

[joamatab]

Hi Joel,

this sounds great, thank you for your PR

Yannick has a PR for improving the tidy3d plugin and expanding it to arbitrary layerstacks

Ideally we can reuse as much code as possible for all the FDTD plugins (lumerical, tidy3d, meep and fdtdz)

@yaugenst
@simbilod

[simbilod]

Great work Joel!

There was some undocumented code to inspect port modes over at https://github.com/gdsfactory/gplugins/blob/main/gplugins/gmeep/get_port_eigenmode.py

The MEEP plugin was one of the first ones written so it is lagging in the more advanced features of gdsfactory (like proper LayerStack integration).

It would be great to make this handling of multimodes source s, monitors, and s-parameters standard across the various FDTD plugins as Joaquin is saying.

[yaugenst]

Hey @joelslaby, thanks for the effort! I think this is great and since it's a relatively small change we can just merge it @joamatab? The API changes will require refactoring of most of the plugins anyways, which is well beyond the scope of #222.
If you would like to contribute on that end you could check out the discussions in #139 and #142. There hasn't been a lot of activity lately but it is in the works.

[joamatab]

fixed by #222