Inverse design plugin¶

This notebook introduces the "Inverse Design" (invdes) plugin of Tidy3D.

The goal of invdes is to provide a simpler interface for setting up most practical inverse design problems. It wraps the lower-level autograd support of Tidy3D to perform the gradient calculations, but allows the user to focus on the important aspects of their design without getting into the details of autograd.

In this notebook, we'll give a simple demo showing the inverse design of a 1 -> 3 splitter using the inverse design plugin.

We first import our main packages, note that we will import the invdes plugin as tdi to make it easy to access.

Setting Up the Inverse Design problem¶

The invdes problem works by constructing an InverseDesign object that contains all of the information about the problem we wish to optimize. This includes some base information about the simulation itself, information about the design region, and which monitors our objective will depend on. We then run the InverseDesign object using an Optimizer, which returns an object that can be analyzed or used to continue the optimization, as needed.

In the next few cells we will define all of the components we need to make an InverseDesign, but to start we will define some global parameters used throughout the notebook.

       |---------|===== -> 
       |         |
-> ====+         |===== ->
       |         |
       |---------|===== -> 

Next we define some quantities derived from these parameters.

Define Base Simulation¶

Next we want to define the base td.Simulation that contains the static portions of our inverse design problem.

For this, we will make a bunch of regular tidy3d components (excluding the design region) and put them into a td.Simulation.

Let's visualize our base simulation.

Note: we have not added a design region yet, so for now we will draw an empty rectangle to indicate where that will go.

Note that our simulation is lacking a central coupling region. We will define that in the next step.

Define the Design Region¶

Next, we will introduce the DesignRegion component of the invdes plugin. This component contains fields that describe the design region and how it is rendered into a td.Structure as a function of the optimization design parameters.

For now, we only support "topology optimization" design structures (pixellated permittivity grids) through a TopologyDesignRegion, but in future versions we will introduce shape and level-set design regions.

The TopologyDesignRegion combines geometric information (size, center) about the design region with some information describing the pixellated grid. Furthermore, it also accepts a list of transformations and penalties, which respectively determine how the permittivity is rendered and how the optimization will penalize various expressions of the design region. We will explore each of the features below.

Discretization¶

The TopologyDesignRegion contains a pixel_size parameter, which sets the resolution of the permittivity grid and also determines the shape of the parameter array.

The pixel_size is also passed to the various penalties and transformations to allow them to work properly with the design region.

If not specified in a later step, this pixel_size will be used to set the FDTD grid size of the structure in the final Simulation. It is therefore a good idea to either set it to a low value (about equal to the simulation grid cell size) or manually set the mesh override structure resolution in the TopologyDesignRegion.mesh_override_dl field to overwrite it.

Transformations¶

The TopologyDesignRegion.transformations are specifications that tell the design region how to transform the supplied optimization parameters into a "material density" that is used to construct the permittivity grid. For example, a FilterProject transformation applies a conic filter convolution followed by a hyperbolic tangent function projection. If multiple transformations are added to the design region, they will be evaluated one by one, from beginning to end, on the optimization parameters.

Penalties¶

The TopologyDesignRegion.penalties are specifications that tell the optimizer how to penalize the material density corresponding to this design region. For example, an ErosionDilation penalty will look at the material density of the region (state of the parameters after all transformations have completed) and evaluate it based on whether the material density is invariant under erosion and dilation, a good proxy for feature size compatibility. Penalties have a .weight that can be used to tune their relative contribution to the objective. The total penalty contribution to the objective function is the weighted sum of penalties added to the design region.

Note: the convention used is that we wish to maximize our objective function. Penalties subtract from the objective. Therefore, a positive penalty weight corresponds to a negative contribution to the objective function.

Getting Parameter Arrays¶

When optimizing, we will update an array of design parameters. Therefore, the DesignRegion accepts an array of these parameters when being converted to tidy3d Structure objects or when evaluating penalties or the material density values.

The shape of this array is automatically determined by the geometric parameters and pixel_size of the TopologyDesignRegion. This shape can be accessed as a tuple from design_region.params_shape.

To make it convenient to initialize parameter arrays of the proper shape, there are a few properties of the TopologyDesignRegion instance:

• TopologyDesignRegion.params_random (creates an array uniformly sampled at random between 0 and 1)

• TopologyDesignRegion.params_ones (creates an array of all 1)

• TopologyDesignRegion.params_zeros (creates an array of all 0)

These properties can be combined together to conveniently set up your parameter array, for example:

Converting to Structures¶

Given an array of parameter values, this TopologyDesignRegion object can be exported to an equivalent td.Structure.

Here's an example using the params0 array we just defined.

Let's plot the permittivity values of the custom medium contained in this structure.

We can see the influence of the FilterProject object in smoothing out the features.

Inverse Design object¶

Next, we put the design region, simulation, and post-processing function together into an InverseDesign object, which captures everything we need to define our inverse design problem before running it.

Note: the output_monitor_names field is used to specify which monitors to use in the objective function. If they are not supplied, invdes will automatically include all compatible monitors.

The InverseDesign object can be exported to a td.Simulation given some parameters using the to_simulation(params) method.

Let's do this with a set of parameters all at 0.5 as it's a better starting point for this specific problem.

It can be useful to run the initial problem to ensure it looks correct before optimizing. For convenience, the to_simulation_data() method generates the simulation and runs it through web.run() to return the SimulationData, which can be visualized.

Optimization¶

Now that we've constructed our InverseDesign object, we can optimize it with gradient ascent. We first define the contribution that we want our simulation result to have in our objective function.

Post-Process Function¶

The next step of this process is to define a post-processing function, which tells our optimizer how we want it to interpret a SimulationData that corresponds to this design. We write this as a regular python function that takes a td.SimulationData as first argument. The function can accept optional keyword arguments involving the optimization history for more control over the objective function.

Reminder that the objective function will be maximized by our objective, minus any penalty values from the DesignRegion. So the sign of this function should take this into account.

In this example, we will try to maximize the minimum power in each of the three output waveguides. This is to ensure that we get an even distribution of power and no ports are ignored.

First we will grab the power at each of the waveguides from the SimulationData. Then, we'll pass the negative of each power to a softmax function to get a differentiable set of normalized weights for each of the ports, with more weight on the smallest values. We'll take the dot product of our powers with these weights and try to maximize this. Normalizing so that a "perfect" splitter gives a value of 1.

Note: there are some utility functions included in the tdi.utils namespace that can make postprocessing a bit easier. Such as utils.get_amps(sim_data, monitor_name, **sel_kwargs), and util.sum_abs_squared(arr). To see all of these available currently, try help(tdi.utils). We'll demonstrate some these in the function below, along with the (commented out) equivalent approach using autograd.

Note: If doing more complex operations in the postprocess function, be sure to use autograd.numpy instead of regular numpy to ensure that the function is differentiable by autograd.

Note: the extra **kwargs contain information passed during optimization about the history and the index of the step. They can be used to schedule changes into the post processing function as a function of the optimization state. We won't go into more detail here but future tutorials will explore how to use these for more advanced optimization.

Optimizer¶

Next, we create Optimizer object to contain all of the parameters that the optimization algorithm will need. This object also provides a few different methods to perform the optimization in different circumstances.

Note: For now, we only support the "Adam" optimization method (AdamOptimizer), but will implement other algorithms as needed later. Adam tends to work quite well for most applications.

The optimizer accepts our InverseDesign, as well as various optimization parameters, such as the number of steps and learning rate, and parameters specific to the algorithm being implemented.

The results_cache_fname is an optional, but very useful argument that will tell the optimizer to save the optimization state to file at each iteration using pickle. It is good practice to include it in case the optimization gets stalled, which can happen in case of a bad internet connection, for example.

In a later section, we'll show how to conveniently load results from this file.

Running the Optimization¶

Finally, we can use result = Optimizer.run(params0) on our initial parameters to run the inverse design problem.

Note, if you leave out the params0, we will start the optimization with an array containing all 0.5 values, which is usually a good choice unless there is a symmetry in your problem that you need to break to get the optimization started.

This will construct our combined objective function behind the scenes, including the penalties and our post-processing function, use autograd to differentiate it, and feed it to a gradient-descent optimizer that we maintain.

Optimization Results¶

The result of an optimization run is stored as an InverseDesignResult object. This object has various fields storing information about the history of the optimization run, including the optimizer states, as well as a copy of the initial InverseDesign object.

Loading an Optimization Result from Backup File¶

If your optimization run was interrupted before you could get the result object. You can load if from the optimizer.results_cache_fname, if it was defined before. This file gets saved at every iteration with the most up to date InverseDesignResult so it should have the most up to date history.

Continuing an Optimization Run¶

To continue an optimization run from where it left off, you can use Optimizer.continue_run(results), passing in the InverseDesignResult. As the InverseDesignResult stores the previous states of the optimizer, it can continue the optimization without loss of information. The return value of this method will be a new copy of the InverseDesignResult with the combined data.

Note: A convenient way to continue an optimization in just one line is to use Optimizer.continue_run_from_history(). This method combines .continue_run() with the backup file in the results_cache_fname to continue a run from the history saved to disk.

Analyzing and Exporting Results¶

The InverseDesignResult itself has a set of methods for analyzing results and exporting to various formats.

Plotting History¶

We can quickly view the optimization history, including the penalty and postprocessing function contributions.

Grabbing History Data¶

InverseDesignResult objects maintain a history dictionary that stores the various parameters over the course of the optimization.

They also have some methods to conveniently grab data from that history, as shown below:

Finally, we are able to quickly grab the last Simulation and SimulationData from the results, making it easy to plot final devices, field patterns, or export to GDS file.

Note: to get the simulation at a specific index i in the history, call sim_i = result.get_sim(index=i).

Exporting to GDS¶

Use the regular GDS export functions defined in the sim_last to easily export to GDS.

Multi-Simulation Objectives¶

In many cases, one would like to perform an optimization with more than one base simulation. For example, if optimizing a multi-port device, it is very common to have objective functions that share a single design region, but each simulation involves a source placed at a different port, to compute a scattering matrix, for example.

To handle this use-case, the invdes plugin includes an InverseDesignMulti class. This object behaves similarly to the InverseDesign class, except it allows for a set of multiple td.Simulation instances. Additionally, the postprocess_fn now accepts a list of td.SimulationData objects as first argument, which allows the user to write an objective function over all simulation results.

Here we'll run through a simple example, where we'll place a source at each of the 3 waveguides on the right (each in a different simulation) and then measure the sum of the power measured on the waveguide on the left. Note that this objective function is similar to the one we optimized earlier, but involves three separate simulations, just for demonstration purposes.

First, we'll switch up our sources and mode monitors.

Make a simulation for each of the independent sources.

We also need to construct a post-processing function that will tell the optimizer how to post process the data from each of the simulations into a single objective.

We'll also specify the output monitor names for each of the simulations, to keep unnecessary warnings from popping up.

Finally, we combine everything into an InverseDesignMulti object.

In an analogy to the InverseDesign from the previous section, this object will generate a set of td.SimulationData objects under the hood and use td.web.run_async to run each of them in parallel.

After the simulations are run, the combined post-processing function will be applied to the combined data to give the final value, minus any penalties in the shared DesignRegion.

To run this, let's make a new optimizer with this multi-design. We'll save the results to the same file as before.

And use the continue_run_from_history() to pick up where we left off.