schema-backed postprocess option for invdes

[tylerflex]

Currently it's almost the most simple thing imaginable while still being somewhat useful.

There's a GetPowerMode object that grabs ModeData from a SimulationData, selects data, computes power, and sums with a weight.
There's a WeightedSum that just sums each of these over a single SimulationData.
This object can be added to InverseDesign, meaning that the Optimizer.run() doesn't need to be passed a postprocess function.

postprocess_obj = tdi.WeightedSum(
    powers=[
        tdi.GetPowerMode(monitor_name=MNT_NAME2, direction="+", mode_index=0, weight=0.5),
    ]
)

des = tdi.InverseDesign(
    ...,
    postprocess= postprocess_obj
)

This makes it possible to do the following (assuming users use this approach):

1. Upload Optimizer to our server through web API and get a Result back.
2. Do everything through GUI.

Kind of a tentative working prototype, let me know what you think of the design / naming etc. Don't hold back any criticism, mostly for discussion.

[e-g-melo]

Thanks @tylerflex!

Regarding the schema-defined FOM I have only two comments:

1. I suggest GetModePower instead of GetPowerMode. Although it is not critical, it sounds better to me :)
2. Would it make sense to move weight from GetPowerMode to WeightedSum? For example:

postprocess_obj = tdi.WeightedSum(
    powers=[
        tdi.GetPowerMode(monitor_name=MNT_NAME1, direction="+", mode_index=0),
        tdi.GetPowerMode(monitor_name=MNT_NAME2, direction="+", mode_index=0)
    ],
    weights=[0.3, 0.7]
)

Regarding the interaction between the server-side optimizer and GUI:

1. After defining the FOMs, how will we submit the inverse design optimization to the server? Optimizer.run()?
2. How can we get the tidy3d.plugins.invdes.InverseDesignResult object to show the progress during the optimization?
3. If the user starts the optimization and then closes the project (or similarly closes the Python notebook). Could we get the optimization progress again using, for example, the Task_ID?
4. How can we get the forward and adjoint simulations and group them in the GUI workspace? Batch_ID?

[tylerflex]

Made things more general:

introduced some abstract classes to separate custom, elementary, and combined postprocessing functions for extension later.

changed naming:

• GetPowerMode -> ModePower
• WeightedSum -> Sum (weights are already applied in ModePower.evaluate()).

Added two new ways to create an InverseDesign with these:

• inverseDesign.from_function(fn, **kwargs) from a function of a SimulationData
• postprocess = CustomPostprocess.from_function(fn)

[tylerflex]

Hi @e-g-melo , I just made some changes before seeing your comment. Let me address your questions though:

I suggest GetModePower instead of GetPowerMode. Although it is not critical, it sounds better to me :)

Yea I just changed it to ModePower actually to be easier.

Would it make sense to move weight from GetPowerMode to WeightedSum? For example:
postprocess_obj = tdi.WeightedSum(
powers=[
tdi.GetPowerMode(monitor_name=MNT_NAME1, direction="+", mode_index=0),
tdi.GetPowerMode(monitor_name=MNT_NAME2, direction="+", mode_index=0)
],
weights=[0.3, 0.7]
)

I thought about this, but then it's more to keep track of (weights, which index they refer to). It seemed easier to just stick it in the ModePower, similar to how things are done with the penalties.

After defining the FOMs, how will we submit the inverse design optimization to the server? Optimizer.run()?

web.run(Optimizer()) will run it. but there can be a local option too, similar to ModeSolver.

How can we get the tidy3d.plugins.invdes.InverseDesignResult object to show the progress during the optimization?

we can do various things. There's a print of the most recent state, which we could parse. Or one can just take the result at each step of optimization and parse that. What would be easiest for you?

If the user starts the optimization and then closes the project (or similarly closes the Python notebook). Could we get the optimization progress again using, for example, the Task_ID?

There are some optimizer methods, like continue_run so we can simply call those methods.

How can we get the forward and adjoint simulations and group them in the GUI workspace? Batch_ID?

This is more tricky.. I dont even know how to do this for regular autograd at the moment. Is it possible to do a prototype without this?

[e-g-melo]

As per our Slack discussion, we need to implement a function similar to web.monitor() to query the optimization process running on the backend and then update the visualization in GUI. This function should return the forward/adjoint simulation progress and the InverseDesignResult info. We will call this function every few seconds to keep the GUI interface updated.

Another important feature is an abort function. An estimate_cost is also desirable, but not critical for this first implementation phase.

[yaugenst-flex]

Looks great!

[yaugenst-flex]

Wondering whether terms would be more intuitive instead of operations?

[tylerflex]

the classes are also called Operations so it kind of makes sense. But yea I wonder if there's an even better name for these?

[tylerflex]

terms sounds a bit strange to me.. it's more like elementary_operations but that's too verbose.

[yaugenst-flex]

Yeah don't know, terms only really makes sense in the context of Sum probably. Maybe it's fine as-is..

[yaugenst-flex]

We should decide for either PostProcess or Postprocess. My vote goes to PostProcess

[tylerflex]

agree, replaced every Postprocess with PostProcess

[m-bone]

I agree I prefer PostProcess

[yaugenst-flex]

Does it really make sense to have InverseDesign be able to construct a CustomPostProcessOperation? Why does only postprocess get this kind of special treatment?
I think there should not be multiple ways of constructing invdes objects from postprocess functions if those ways are functionally identical.

[tylerflex]

So the idea was to make this

postprocess = CustomPostprocessOperation.from_function(fn)
des = InverseDesign(postprocess=postprocess, ...)

a bit simpler

des = InverseDesign.from_function(postprocess=postprocess, ...)

and save the user from having to know about CustomPostprocessOperation.

The reason this gets special treatment I guess is that I think it will be used often enough (especially since we'll recommend users passing functions into Optimizer.run(f) to switch to this). and the CustomPostprocessOperation basically does nothing but be a class that the InverseDesign schema recognizes.

What do you think?

[yaugenst-flex]

Does this really need to inherit from ABC again?

[tylerflex]

good question. I'm starting to doubt how I thought ABC classes worked. The idea though was that this ElementaryPostprocessOperation is still abstract in the sense that we just use it for grouping / subclassing. We don't want the user to initialize one.

I thought that meant making it inherit directly from abc.ABC but not I don't know. seems you can still initlize it. Have I been using ABC wrong this whole time? when should we use it?

[yaugenst-flex]

So in principle this works:

class A(abc.ABC):
    @abc.abstractmethod
    def f(self):
        ...

class B(A):
    def g(self):
        ...

b = B()  # TypeError

However, if you use composition like, e.g., A(float, abc.ABC), then A can be instantiated and is not abstract anymore. So yeah, since everything inherits from BaseModel, I don't think any of our ABCs really work as intended 😄
This can be solved through some fiddling with abc.ABCMeta but I have to double check, forgot how exactly that works.

[tylerflex]

closing in favor of #1959 and #1848 but @yaugenst-flex just FYI if you want to see what I sketched out regarding these things in invdes