Decoupled mode solver

[e-g-melo]

Current

For legacy reasons, our mode solver is closely linked to FDTD, as it is also used to run simulations for ModeSources and ModeMonitors. However, this architecture has led to some usability issues when users focus solely on mode simulations.

The interaction between the simulation bounding box (inherited from the original coupling with FDTD) and the mode plane is not very convenient and can be challenging to understand. Additionally, there are configuration settings that depend on the 3D bounding box, such as symmetry and mesh. This creates some challenges when defining a simulation plane for conducting mode analysis on a specific cross-section of more complex structures containing asymmetries, such as active devices. Generally, if the mode analysis is not coupled with an underlying FDTD simulation, users expect the simulation plane to be entirely independent of the surrounding medium.

Below we provide some examples of situations where the setup of mode plane symmetry is not convenient for users.

Here, we have an example of a situation where the user would expect a symmetric mesh in the mode plane. However, it turns out to be asymmetric due to the impact of other structures outside the mode plane. Users might not easily perceive this behavior, which could potentially generate inaccurate results.

Lastly, the 3D Bounding Box crops the model plane in Python. This is managed in the GUI by extending the 3D Bounding Box based on the model plane's position and size. However, the differing behaviors between the GUI and Python clients are not ideal.

Requirement

Python Client

Some changes would be required on the Python side. Ideally, we should have a mode solver decoupled from the FDTD simulation needs. Perhaps the new ModeSimulation class could serve this purpose if we could develop a new, independent solver. This new solver should:

1. Assign symmetry directly to the mode plane.
2. Create the simulation mesh considering only the mode plane domain.
3. Enforce a finite mode plane.
4. Doesn't crop the mode plane by the 3D bounding box.
5. Add a method to create a 2D simulation limited to the mode plane domain. Automatically slice the structures and apply the correct boundary conditions in zero-dimensional directions. That would be useful for reducing the mode simulation upload time from Tidy3D and PhotonForge Python users when working with very large models.

Web Client

Once the new mode solver is available in Python, we will need to reorganize the left panel, removing unused settings and making the setup workflow very intuitive and straightforward.
Potential changes:

• Remove the "3D Bounding Box"
• Move "Background Medium" into "Medium"
• Split "Mode Specification" into "Mode" and "Wavelength".
• Replace "Configuration" with "Solver Settings".

[e-g-melo]

@xin-flex and @tomflexcompute, please feel free to add your comments.

[tylerflex]

cc'ing @daquinteroflex @caseyflex and @momchil-flex

[daquinteroflex]

Just thought to link to the discussions in #2208

Ultimately this is what a self-contained ModeSimulation would enable (at least we can work in this direction in line with MC is my appreciation of this so far), but the previous issue is also backwards compatibility with the ModeSolver from our last discussions. Casey will know in more detail re #1838 , but this issue of translation between simulation definitions is something we should standardise for all solvers and we've got some ideas about this too - but need to fit this into the roadmap plans too.

[momchil-flex]

So we can discuss this in more detail but my understanding is that ModeSimulation already achieves all of this, when defined as a 2D domain through its center and size and without passing a plane argument.

• Assign symmetry directly to the mode plane.
• Create the simulation mesh considering only the mode plane domain.
• Enforce a finite mode plane.
• Doesn't crop the mode plane by the 3D bounding box.

One caveat about the simulation mesh was pointed out by @tomflexcompute recently. Basically, the mesher does throw away all geometries that are completely outside of the mode plane, so this will not be a problem:

However, if the mode plane is e.g. placed in the ring, then the entire ring will be used for the meshing, so the grid will come out asymmetric. I think that this is not that bad though.

• Add a method to create a 2D simulation limited to the mode plane domain. Automatically slice the structures and apply the correct boundary conditions in zero-dimensional directions. That would be useful for reducing the mode simulation upload time from Tidy3D and PhotonForge Python users when working with very large models.

So both ModeSolver and ModeSimulation already contains such a method, reduced_simulation_copy, and by default we call it in web.run if there are custom media in the simulation. One can also set reduce_simulation=True to force web.run to always reduce the simulation.

@e-g-melo let me know your thoughts after these clarifications. I think you should test ModeSimulation and see if it addresses all or most of your concerns. We've been waiting for a GUI workbench for it before we incorporate it in our documentation, so for now it's been kind of obscure...

One thing that I know we need to still think about is how boundary conditions and symmetry are set. We might want to move all of that to the ModeSpec, so that they can be set by ModeMonitor-s and ModeSource-s too.

[e-g-melo]

So we can discuss this in more detail but my understanding is that ModeSimulation already achieves all of this, when defined as a 2D domain through its center and size and without passing a plane argument.

• Assign symmetry directly to the mode plane.
• Create the simulation mesh considering only the mode plane domain.
• Enforce a finite mode plane.
• Doesn't crop the mode plane by the 3D bounding box.

Hi @momchil-flex! Thanks for the clarification! I agree that 2D simulations are usually simpler, with the waveguide center coinciding with the simulation domain center. However, in some cases, we can still have some usability issues with setting up symmetry or defining the mode plane. That should become more common when users start to run more heat/charge->mode simulations. This is an example from GUI.

One caveat about the simulation mesh was pointed out by @tomflexcompute recently. Basically, the mesher does throw away all geometries that are completely outside of the mode plane, so this will not be a problem:

In this ModeSimulation the mode plane was defined completely outside the ring, and it is symmetric to the waveguide, but the mesh is not symmetric. Is it expected?

So both ModeSolver and ModeSimulation already contains such a method, reduced_simulation_copy, and by default we call it in web.run if there are custom media in the simulation. One can also set reduce_simulation=True to force web.run to always reduce the simulation.

I tried this web.run(mode_sim._mode_solver, task_name="mode_solver", reduce_simulation=True), but it doesn't seem to work.

But indeed, this one web.run(mode_sim._mode_solver.reduced_simulation_copy, task_name="mode_solver") works. Do we have any specific reason to keep a reduced 3D simulation domain instead of a 2D one?

From all those points, setting up symmetry is maybe the most critical one, so adding symmetry (and maybe boundary conditions) to ModeSpec seems quite interesting.

[momchil-flex]

@e-g-melo I think you might still be not using ModeSimulation exactly right for your purposes. Namely, you can completely skip the plane argument and pass the center and a 2D size directly to the ModeSimulation.

So we can discuss this in more detail but my understanding is that ModeSimulation already achieves all of this, when defined as a 2D domain through its center and size and without passing a plane argument.

• Assign symmetry directly to the mode plane.
• Create the simulation mesh considering only the mode plane domain.
• Enforce a finite mode plane.
• Doesn't crop the mode plane by the 3D bounding box.

Hi @momchil-flex! Thanks for the clarification! I agree that 2D simulations are usually simpler, with the waveguide center coinciding with the simulation domain center. However, in some cases, we can still have some usability issues with setting up symmetry or defining the mode plane. That should become more common when users start to run more heat/charge->mode simulations. This is an example from GUI.

So if you take the entire scene here and pass it to a ModeSimulation with center and size that are given by the plane that is shown, you can define symmetry w.r.t. that plane, not w.r.t. the original simulation domain.

One caveat about the simulation mesh was pointed out by @tomflexcompute recently. Basically, the mesher does throw away all geometries that are completely outside of the mode plane, so this will not be a problem:

In this ModeSimulation the mode plane was defined completely outside the ring, and it is symmetric to the waveguide, but the mesh is not symmetric. Is it expected?

Again, my guess is that here you still used a plane argument plus a 3D size for the ModeSimulation, while if you instead skip the plane and define the 2D size directly, you should get what you're aiming for.

So both ModeSolver and ModeSimulation already contains such a method, reduced_simulation_copy, and by default we call it in web.run if there are custom media in the simulation. One can also set reduce_simulation=True to force web.run to always reduce the simulation.

I tried this web.run(mode_sim._mode_solver, task_name="mode_solver", reduce_simulation=True), but it doesn't seem to work.

But indeed, this one `web.run(mode_sim._mode_solver.reduced_simulation_copy, task_name="mode_solver")` works. Do we have any specific reason to keep a reduced 3D simulation domain instead of a 2D one?

Yikes, indeed, there seems to be a bug with the reduce_simulation argument of the run function! I will take note to fix this. One thing that you should understand though is that the reduced simulation copy tries to copy the exact setup of the original system, just in a smaller domain. So while structures are dropped, the grid that may have been affected by the structures in the original setup is copied to the reduced copy. So the asymmetric grid would still appear after the reduction, while it will not appear if you use a ModeSimulation with a 2D domain size. Does that make sense?

[e-g-melo]

Hi @momchil-flex! If I skip the plane argument, it works for symmetry, but I still get an asymmetric mesh when symmetry is OFF.

• Symmetry = (0, -1, 0)

• Symmetry = (0, 0, 0)

[e-g-melo]

@momchil-flex, we need to deal with some situations in the Mode workbench. For example:

1. The user builds a 2D/3D model and conducts a mode analysis.
2. The user creates a complete 2D/3D model and performs a parameter sweep on the mode plane position.
3. The user creates a complete 2D/3D model, defines the mode plane at any location, runs a mode analysis, and then converts that project to FDTD.
4. The user generates a HeatCharge simulation and converts a 2D/3D simulation domain to Mode. In Mode, the user needs to define the mode plane at any location.

Skipping the mode plane should work for case 1. However, for cases 2, 3, and 4, users will likely want to visualize the entire device and the mode plane position simultaneously while setting up the simulation. If we skip the mode plane to address the symmetry setting, users will see only the 2D cross-section after running the simulation (or if the tasks are submitted from Python), which would result in a non-ideal experience. So, adding symmetry directly to ModeSpec sounds good to me.