Additional optimization examples

[mfschubert]

It would be good to add additional examples to the optimization docs. Possibilities are:

• level set optimization
• basic shape optimization (e.g. diameters and origins of circles)
• more sophisticated shape optimization, e.g. https://github.com/aadityacs/PhoTOS
• genetic algorithms, for problems such as the bayer sorter (reference solution here was obtained using a GA)

[lucasgrjn]

Hey @mfschubert,

I am always happy to following the direction invrs-io is taking!
Currently, I don't have time to invest myself in any open-source project right now but here was some examples I putted aside thinking they will be an interesting addition to gym.

• Interpretable inverse-designed cavity for on-chip nonlinear photon pair generation which is a grating optimized for 3 colors. It is explained on the articles they used EMopt, but it should be possible (even easier) to use directly another FDFD solver/implement a simple one.
• Inverse design of digital nanophotonic devices using the adjoint method depicts the design of 2 splitters (a simple 1-2 and a polarization splitter) using holes only. They also try different methods to obtain the values of hole radii.
• Fabrication-constrained nanophotonic inverse design and Inverse Design and Demonstration of a Compact on-Chip
  Narrowband Three-Channel Wavelength Demultiplexer could be nice components examples for the level-set. They were made with a proprietary version of Stanford SPINS. But again, it should be possible to get over it.
• Leveraging continuous material averaging for inverse electromagnetic design provides an example to how to optimize a taper with some level-set (once again with EMopt.

I would be happy to help on it later this year (closer to the end of the year), but in any case, I will be happy to discuss on it!

[mfschubert]

Hi @lucasgrjn , thanks for chiming in and sharing these suggestions. I definitely appreciate discussions and contributions!

In general, I see several potential tasks here. The first relates to examples demonstrating different optimization approaches applied to gym challenges; basic implementations could be used in the invrs-gym docs, and then subsequently an implementation that conforms to the invrs-opt api could be added to the invrs-opt package. (I have also been chatting with @aadityacs, @rahulkpadhy, and @skdebnat about this.)

The second task relates to additional gym challenges, and challenges backed by additional simulation engines. In general, it would be useful to have such challenges, as these would serve as examples to users facing a problem that requires a alternate simulator. If the simulator is a general-purpose one, that is ideal, as it would be of greatest utility to users. For this, I am definitely keen to hear suggestions.

Finally, it strikes me that building a gym challenge with some simulators may be quite involved---or at least more complex than simply using the simulator to compute value and gradient of some objective. In this case, a simpler and still value-adding exercise could be to interface an invrs-opt optimizer to a problem backed by the simulator.

[lucasgrjn]

In general, I see several potential tasks here. The first relates to examples demonstrating different optimization approaches applied to gym challenges; basic implementations could be used in the invrs-gym docs, and then subsequently an implementation that conforms to the invrs-opt api could be added to the invrs-opt package. (I have also been chatting with @aadityacs, @rahulkpadhy, and @skdebnat about this.)

Glad to see you are digging in optimization on multiple fields!

The second task relates to additional gym challenges, and challenges backed by additional simulation engines. In general, it would be useful to have such challenges, as these would serve as examples to users facing a problem that requires a alternate simulator. If the simulator is a general-purpose one, that is ideal, as it would be of greatest utility to users. For this, I am definitely keen to hear suggestions.

For this part, you already contribute a lot for the RCWA of ffmax, for the FDFD we have ceviche which is also a great tool. One of the most important one, the FDTD can rely on Meep. But I have really high expectations from hyperwave or Khronos, especially since they are/will be build with an interoperability logic (meaning they can be launch in a simple x86/ARM computer or some HPC GPUs) and a differentiability logic (to compute gradients with the adjoint easily). Depending how far you want to push the integration, automation with CI/CD, small challenges should be able to be run on this kind of tools.

Finally, it strikes me that building a gym challenge with some simulators may be quite involved---or at least more complex than simply using the simulator to compute value and gradient of some objective. In this case, a simpler and still value-adding exercise could be to interface an invrs-opt optimizer to a problem backed by the simulator.

I agree at 100%. At the end of the, we cannot go in all the directions and having a set of unified tool is necessary. Especially if you want solid foundations to build all the challenges on them. (Especially since Stanford SPINS and EMopt are no longer really supported).

PS: I think you already know all I wrote above and even more, I simply post it for discussion or if people interested find the post.

[mfschubert]

Yes, I am also optimistic about some of the new FDTD tools being developed (luminescent.jl is another one).

One thing that I am keen to retain is ease of install and use, which may not be the case for all options. Specifically, everything is currently pip-installable and it would be ideal to retain this.

A solution here could be to make challenges that depend a more "difficult" simulator optional in the install.