Improve the PML placement in mode solver

[e-g-melo]

Current

When we set the PML in mode solver, it is placed within the simulation plane. For example, here num_pml = [7, 12].

So, if the user sets a large number of PML layers, for example num_pml = [7, 20], we can have situations like this:

Users would not expect it, and if they don't know how the PML is placed, they might have issues with the results.

Requirement

Place the PML surrounding the mode plane. For example:

[caseyflex]

Thanks @e-g-melo, I think we need to discuss exactly how to handle this, but it would be good to unify BoundarySpec PML with ModeSpec num_pml, in ModeMonitors / ModeSolver and in ModeSimulation.

One option is to add a 2D mode_boundary_spec field to ModeMonitor, ModeSolver, and ModeSimulation. This might be better than adding it to ModeSpec because it modifies the actual geometry and grid. This field would be treated in the mode solver like the boundary_spec pml - extend the simulation and grid (assuming structures extend into it), then superimpose PML on the new region.

If a ModeMonitor doesn’t extend across the entire FDTD simulation, would the resulting grid in the PML region of the ModeMonitor agree with the grid in the surrounding region of the FDTD simulation?

Of course not all boundary types would be supported - just PEC and PML I think.

Then we could deprecate num_pml, add an option “auto” to just use the mode_boundary_spec pml (maybe as default), and keep manual num_pml for backwards compatibility.

There are a lot of different use cases here to consider, as well as implementation subtleties.

[e-g-melo]

@caseyflex, these are all good points.

Maybe the ModeMonitor, ModeSolverMonitor (and ModeSource?) would be the most critical cases. I think we should not perturb the FDTD simulation grid because it would be difficult for users to understand why the grid changes when they add a monitor at another position.

So that could mean we need to agree with the surrounding grid or create a kind of "artificial" PML grid surrounding the mode plane only when calculating the modes.

If we agree with the FDTD simulation grid, in some cases, we can have interference from nearby structures that are very close but not included in the mode plane. For example:

So, in that case, we would need to represent the PML region on the mode plane plot, which would be problematic in GUI.

On the other hand, if we create an artificial PML grid surrounding the mode plane only when calculating the modes, we could also have difficulties to consider structures that go into the PML region.

[caseyflex]

@e-g-melo yeah, I agree it would be an "artificial" PML grid, rather than perturbing the FDTD grid.

Regarding difficulties from nearby structures in the PML region -- yeah, I think we discussed at some point the ability to automatically extend structures in a translationally-invariant way into the PML. If we supported that, then the PML region around the mode plane could, for the purposes of the mode solve, contain the extended structures rather than whatever is actually there in the FDTD simulations. However there are some subtleties regarding extending angled waveguides or other structures I guess, it won't always work? At least in the current setup with PML inside the mode plane, you can know if the mode plane contains other structures.

[e-g-melo]

@caseyflex, maybe, for now, we can keep it inside the mode plane and focus on improving the usability since a definite solution should take considerable time.

What about creating a method to return the "effective dimension" of the mode plane after placing the PML? For example, if the mode plane dimension is [3, 2], and the total PML thickness in the orthogonal directions is [0.5, 0.7], the mode.plane.effective_dimension could return [2.5, 1.3]. Then, we could raise a warning to explain to the users about the PML placement if the effective dimension is smaller by, for instance, 10%.

[momchil-flex]

I think you guys have basically nailed down why I set it up the way it currently is, yea.

I think refactoring the definition out of ModeSpec.num_pml into a proper boundary spec definition makes sense and I see no conceptual issue. In fact it will further improve things in that we could expose the pml parameters to the user (sometimes tuning them a bit can help e.g. when trying to resolve low radiative loss), and we want to even support Bloch boundaries at some point.

The hard question really is how to place the PML outside while avoiding the issues above. Just a quick note, one more thing which used to be an issue but maybe is resolved now: previously, .dot would only work between field datasets defined on the same grid, which is why it was important for a mode monitor to have the mode fields computed on the exact same grid that the simulation fields are stored on. However, with #1526 this may not be an issue anymore.

I do agree that nevertheless making the boundaries translationally invariant is non-trivial and what @e-g-melo proposes sounds interesting as a first fix. We could even plot the "inside" and the "pml" regions of the monitors in different colors?

[e-g-melo]

Sounds good! If we can return the PML thickness in all four plane edges, we can show it in different colors on monitors.