RF Autograd Patch Antenna Optimization with PEC Boxes

[groberts-flex]

This notebook optimizes two patch antenna structures, the first being a simple two-dimensional patch where the width and height are tuned to find the resonance. The second optimization uses a larger amount of design freedom to tune the spacings and sizes of multiple boxes to achieve dual-band operation.

All the outputs should be in the notebook from my most recent run through of the whole thing, but let me know if that isn't the case when you download it.

[tylerflex]

This is a really awesome demo! It works super well, nice job @groberts-flex !

I'll pre-approve here, because my comments are mainly just some minor things that came up when reading through the text:

The introduction paragraph could be perhaps split up into a few separate paragraphs. Or perhaps can be smoothened a bit to really highlight what the innovation is in the notebook. For example, just rephrasing what you wrote, something like

This notebook demonstrates the use of inverse design for the optimization of antennas.

A simple rectangular patch antenna, as explored in our Antenna Characteristics notebook, is primarily defined by two parameters: its width and height. These are tuned to make the antenna resonate at a desired frequency and to match the impedance of its feed line. However, to achieve wider bandwidth or specialized features like circular polarization, designers often move beyond simple rectangular shapes. For instance, our Circularly Polarized Patch Antenna notebook details a non-rectangular radiator with parasitic strips to produce circularly polarized waves.

As antenna geometries become more intricate, the number of design parameters can increase dramatically, making traditional tuning methods inefficient. This notebook demonstrates a more powerful approach using gradient-based optimization in Tidy3D. This technique, enabled by the adjoint method and automatic differentiation (autograd), allows for the efficient and simultaneous optimization of all geometric parameters, also known as inverse design.

We will illustrate this process with two examples.
	1	First, we'll perform a straightforward optimization to find the ideal width and height of a rectangular patch for a single target frequency.
	2	Second, we will optimize a more complex antenna for dual-band operation. This design includes an optimizable inset, fins, and passive radiating elements, requiring the optimizer to simultaneously tune the dimensions and positions of all structures.
In both cases, we will hold the substrate material and thickness constant, focusing exclusively on optimizing the antenna's shape.

The two optimization geometries are shown below. Both antennas consist of a metallic patch on a substrate with a ground plane, are excited by an offset feed line, and radiate into free space. The first design is a simple rectangle defined by just two parameters, while the second, more complex design involves optimizing the dimensions and relative positions of multiple structures at once.

[1] we might want to remove setting log level error unless the warnings are unfixable?
[2] might be also useful to mention that frequencies are Hz , at least in the comment eg frequency range (Hz)

In general, there are a lot of very long functions defined up front before they ever get called. I am slightly worried it might be hard to follow for beginners. However, I'm not sure if I saw any obvious ways to improve this. this is probably one of those applications where it's hard to put everything inside of 1 single notebook without some python utility modules so I wouldn't stress about it .

Thanks!

[tylerflex]

Oh yea and dont forget to add this notebook to the appropriate .rst file so it gets added to the docs.

[yaugenst-flex]

Thanks @groberts-flex, heroic effort! I agree it looks great overall, so I'll also mostly resort to nit-picking:

1. The introduction is a ~20 line paragraph. Splitting this into a couple of shorter paragraphs would make this a lot easier to digest.

2. The leading image is cut off for me on the right (see screenshot, and notice the scroll bar too):

   

   Let's try to make these illustrations fit?

3. In cell [2], sub_z is assigned twice to different values.

4. The first optimization loop prints a lot of information at every iteration. I guess this is a matter of taste, but I find it quite noisy and it makes it a bit harder to scroll through the notebook. I feel like trimming this down would help. For example, gradients, updates, and params are somewhat redundant/interchangeable no? And/or reducing the print cadence (also for the second optimization). Basically, the longer these logs are, the more these will eclipse the actual figures and overall flow of the notebook.

5. Also not sure if this is possible, but can we suppress the validation logs? They're pretty distracting in that loop.

6. I noticed a couple of typos ("optimziation", "inital"), but i think these should be caught by the spellcheck. On that note, the notebook needs a ruff pass.

[groberts-flex]

Thank you @tylerflex and @yaugenst-flex for the really helpful comments! I tried to get them implemented and below are a few notes responses to each.

Tyler's comments:
I really liked how your rewritten intro read and essentially dropped that in with a few small changes.

1. I was able to fix one of the warnings that is coming up but the other warning that pops up is the substrate structure being half a wavelength from the PML (and also warnings about RF usage being billed differently in the future). I went the route of the other patch antenna notebook that also has a similar substrate setup where I let those warnings come out before the optimization so that users can be aware of them, but then turned them off for the optimization loop so they don't crowd the output a bunch.
2. good point on the frequencies, updated!

Yannick's comments:

1. good point, updated according to Tyler's suggestion and think it's more digestible now!
2. thanks for noticing this - interestingly it doesn't cut off when I have it in my browser, but shrunk the figure sizes a bit so it also doesn't require a scroll in the GitHub preview to be safe
3. good catch
4. trimmed things down a bit - realized some of the extra info was just more helpful for me when developing and agree it's much cleaner to have it just be the parameters. I also reduced the printing cadence in both optimizations.
5. these should suppress now on re-run which I'll do before publishing
6. did the ruff pass, but how do I run the spell checker?

[yuanshen-flexcompute]

@groberts-flex This is a tremendous effort and an exciting showcase of our new functionality! Great job on developing this feature.

That said, I do have some big picture concerns about its presentation. Who is the target audience for this notebook?

• Given its length and complexity, beginner and even intermediate users of Tidy3D will be intimidated and likely not finish reading the notebook. Advanced users of Tidy3D familiar with existing adjoint optimization features might be able to digest it, but they are a minority and probably not the target audience.
• If we are trying to attract new RF users, we do not want to present them the impression that our adjoint optimization is difficult to use and requires expert-level coding skills/API knowledge. Unlike the photonics field, it is not as common for RF users to have a PhD degree.

Some other concerns:

• What is the FC cost of running each optimization? It would be good to provide feedback with every step. Users running this notebook on their own dime will probably care it is too large.

With all that said, I have a few suggestions:

• Would it be possible to sequester the non-essential code (from a pedagogical perspective) into a separate .py file in the misc folder that is imported at the beginning? I'm referring to methods like plot_antenna_comparison, plot_antenna_evalution etc., that are not critical to understanding the adjoint workflow. This will reduce the amount of code that the reader has to parse and avoid confusion about the main learning points.
• Would it be possible to show the FC cost of each optimization iteration?
• There are a lot of wrapper functions in the notebook that call other wrapper functions. For example, evaluate_single_antenna calls evaluate_antenna calls create_modeler and params_to_box_single_patch and create_sim_with_patches and so on. This functions are also defined across disparate cells in the notebook. This can obfuscate the workflow and make it even more difficult for the reader to understand the "sequence of events". Would it be possible to reduce the number of wrapper functions, or if that is not possible, present the entire workflow in a logical sequential fashion? (Maybe even include a visual aid, like a flowchart?)
• Instead of using a dense grid enforced by the MeshOverrideStructure, have you experimented with using LayerRefinementSpec instead? (For example, see the Edge Feed Patch Antenna benchmark notebook.) I wonder if this can further reduce run time and cost while offering similar performance.
• Finally, have you considered splitting the notebook into two notebooks? The first one could cover the basic patch antenna W and H optimization, and serve to introduce the adjoint optimization workflow. The second notebook could then extend that workflow to the more complicated design. Having two shorter notebooks could improve approachability.

All in all, I think this is a great notebook with exciting content, but just needs to be packaged in a more approachable fashion. :)