Add automatic calculation for num_freq on broadband sources

[e-g-melo]

Current

Users set num_freqs manually. This parameter is not intuitive, and it takes time to understand and adjust its value.

Requirement

We would like to include an optional auto setting for this parameter. That would help first-time users to set up broadband sources. PhotonForge already has such a feature.

[lucas-flexcompute]

With photonforge development, I really don't know when I'll get around to work on this, but the basic equation we use is:

num_freqs = 1 + int(np.arctan(1.2 * (fmax - fmin) / fmed) * 12.0)

[momchil-flex]

Nice. My only worry about setting some default is that in principle in FDTD, there is not much of a requirement on the source bandwidth. Even if you're looking at e.g. the C band, it's common to have a source that is much more broadband than that. The problem with setting num_freqs > 1 for such sources is that if there's a modal cutoff within the source bandwidth (even if far away from the actual frequency range of interest), the injection will be affected, potentially severely, at all frequencies. Back in the day I wasn't sure how to handle this caveat while enabling a default value for num_freqs that is larger than 1.

So the question still is, how do we handle this?

[lucas-flexcompute]

I guess the main effect in this case would be the incorrect input power normalization, right? Or are there other effects in the injection?
I did not worry about injection power because we always calculate relative fractions in the S matrix, but it might matter in general for Tidy3D (or for nonlinear devices, now that I think about it).

[momchil-flex]

So, kind of yes, but things can go very wrong, to the point where the simulation even diverges or at least looks like it. That is to say, the injected power could be way off. This is because the temporal signal of the source may not go down to (close to) zero within the simulation run_time, or may even start ramping up. This is because we fit the frequency dependence of the mode with Chebyshev polynomials, and if there's a sharp change in frequency-domain, these can go haywire in the time domain. And in general if the fields do not decay by the end of the run_time, the normalization can be off in a non-trivial way, namely not just a constant prefactor that affects all monitors, but rather every monitor can have a different wrong normalization.

[lucas-flexcompute]

Is there any chance to validate/check the Chebyshev fit? If it is not valid, fallback to num_freqs = 1 and send a warning to the user.

[momchil-flex]

Only after the modes are computed. But, we could do that during solver run and write the warning to the log.