Potential improvement items for EME solver

[tomflexcompute]

Been testing the EME solver today and it's no doubt a great addition to the FDTD solver. Thanks @caseyflex for the great efforts in the past few months. This is highly requested by a number of users and will be used by many people in the future. Here I list a few potential improvement items from my testing so far. Maybe some of them are already in the roadmap or proposed by someone so feel free to ignore them in that case:

• Currently there is no cost estimate before and after the simulation. Since we only charge the mode calculation, in principle the cost can be computed similarly to a regular mode solver task. Would be helpful to show the cost at least after the simulation. If the same estimate_cost can work for EMESimulation that would be even better.
• When the task is submitted, a message with the link to GUI is provided. Clicking the link leads to a message saying "EME task is not supported on the web currently". Since EME support on the web will take a good amount of time to be implemented, maybe we can remove that message for now.
• When the task is running, there is no progress bar like the FDTD simulation. Would it be possible to provide some sort of progress bar or status indicators so users get a rough sense of the progress? When doing a length sweep of tens of simulations, the simulation time can be quite substantial. Would be good to indicate the task is running correctly.
• In the tutorial it mentions that the S parameter can be projected into a different basis. For simulating a 1x2 MMI for example, this is needed to compute the transmission to the two waveguides. Based on the API reference, doing so requires users to supply a mode field from a mode solver data. However getting this data is not super convenient at the moment. Initially I thought EMEModeSolverMonitor was for this purpose but it turned out not to be the case. Maybe we should provide a way so users can set up a mode solver directly in a EMESimulation? Let me know if I'm missing something and there is already a way to do it.

• freqs in EMESimulation only accepts lists. Regular Simulation also accepts numpy array for example. Would be nice to have the same behavior here for EMESimualtion. Same for scale_factors in EMELengthSweep.

• A few minor issues on the EME tutorial. These are pretty small so no hurry in fixing them. I can fix them later.

1. In the notebook title we only capitalize the first word, i.e. "EME solver".
2. The "Horiba" variant of SiO2 is (artificially) lossy. This loss becomes prominent for long PIC components. In the directional coupler, the transmission becomes noticeably less than one as the coupling region gets longer. Same for the taper. This loss is often not what the user expects to see. For longer components, better to use the "Palik_Lossless" variant.
3. When linking to other notebooks, we typically link to the learning center page for better SEO. The current link to the edge coupler is linking to the docs page.

[caseyflex]

Thanks @tomflexcompute .

Cost estimation and removing the URL are covered in this PR (and python-webapi PR): #1634

Progress bar is a nice suggestion, I can look into it.

You should be able to add a ModeSolverMonitor directly to the EME simulation, and then pass that data to smatrix_in_basis. Does that work for you? I should include an example of this in the demo notebook.

[tomflexcompute]

Thanks for the clarification @caseyflex ! I didn't realize that ModeSolverMonitor also works with EMESimulation. Does the mode solver plugin work with EMESimulation as well? It would be nice to clarify somewhere what works and what doesn't work with EMESimulation.

I'm experimenting with a MMI and that could be a good example to demonstrate smatrix_in_basis. Let me test it a bit more and see if we can publish it.

[caseyflex]

That would be great to have that example @tomflexcompute ! Let me know if you run into any other difficulties with the EME solver.

The mode solver plugin currently doesn't work with EMESimulation, although that should be fixable by replacing Simulation -> AbstractYeeGridSimulation throughout the plugin.