add tutorial about source normalization

[FilipeFcp]

Hi all,
This is the example of source normalization related to issue #900.
Let me know if you think we should add, remove, or modify anything.

It was run using version 2.9-rc.1, with the fixes to the diffraction monitor included.

[github-actions]

Spell check passed successfully for 1 notebook(s).
Generated by GitHub Action run: https://github.com/flexcompute/tidy3d-notebooks/actions/runs/15495491398

[alec-flexcompute]

Excellent work @Filipe, this will be a super useful resource - this answers a number of my questions as well!

A couple comments:

1. Above cell 5, it might help to plot a couple of these simulations, so the user can quickly visualize what you're measuring

2. For the plot in cell 21, maybe connect the data points with a line to better illustrate the behavior

3. Above cell 22, a bit more explanation of what the simulation will do will be helpful

Other than that, I think this is great - super clear, illustrative, and useful!

[tomflexcompute]

Thanks @FilipeFcp . Very helpful content, especially the error on the monitor position, which I didn't realize before.

1. Consider adding doc string to the get_sim function since it's relatively long with many arguments.

2. For plane wave, "|E_0| is proportional to the source plane area" is incorrect right? |E_0| should be proportional to the area**(-1/2) as the figure below shows?

3. Since we are on this topic, shall we spend some time on custom field source and current source normalization just to make the tutorial complete?

[momchil-flex]

Thanks @FilipeFcp, great stuff! A few comments from my side too:

• I am a bit surprised by the diffraction monitor result at 20 degrees. It seems to have jumped quite a lot compared to the trend from the previous degrees. Since you're focusing on that data point exactly, I want to be sure that it's actually correct (I mean, it seems that the error goes down with resolution, but still it looks a bit fishy if there's a sudden jump). Maybe, at least for internal consideration, could you run this with more angles and we can see if there's some discontinuity we need to look at? If there's a discontinuity, I wonder if it may be related to a second diffraction order appearing in the simulation? In which case it would be affected by the simulation domain size.

• For the point dipole, instead of saying for a classical radiating dipole, let's either explicitly say classical radiating current dipole (as opposed to electric dipole, which will be normalized differently), or infinitesimal antenna with a fixed current density as in our FAQ. Also, mention that the formula you give is specific to an electric current dipole in 3D (and maybe link to our FAQ again).

• Just wondering why you use nu for the frequency instead of f as in the rest of our documentation (I believe?), or even just omega directly.

[FilipeFcp]

Hi all.
Thanks for the comments. I've fixed the issue and am now adding the current and custom source components.

@momchil-flex, I did some tests with more angles, and it seems odd. Using 2.9rc, for a plane size of 1 µm:

Changing the plane size to 1.5 µm:

That doesn't happen in 2.8.3:

Is it some issue with the monitor, or should I adapt something in the simulation?

The $\nu$ name was just old habits. I will change to omega to be more consistent with our documentation.

[FilipeFcp]

It gets much better with increased resolution. The previous results used 10 steps per wavelength.

Using 20:

Using 30:

[momchil-flex]

Ok, yeah, this is pretty interesting. In some sense it is showing exactly what I wanted to show: that in some cases, especially when the DiffractionMonitor has to differentiate between roughly equal powers going in both directions, the accuracy can get degraded. Notice that the problems are happening exactly beyond TIR when reflection hits 1, meaning that there's exactly equal powers going in each direction, and the flux at that location is 0.

The problem is that numerically the flux is rather numerical noise on the scale of 1e-6. In the new handling in 2.9.0rc1, I've added some flux normalization similar to what we already do for ModeMonitor-s, which ensures that, in the typical "correct" setups (like in the "back" monitors in this setup), the power recorded by a DiffractionMonitor matches very closely the flux of a FluxMonitor. However, this flux normalization is indeed introducing more noise in the case of flux ~ 0. Increasing the resolution decreases the "noisiness" of the flux around 0, and thus decreases the numerical normalization error.

Understanding now how everything fits together, my suggestion is to preserve the current behavior. I think the increased accuracy in the "correct" setup is worth the potential decrease in the specific case of a DiffractionMonitor placed in a region with (almost) 0 flux.