Spatially-targeted modesolver

[simbilod]

It would be great to have a feature to mode solve in a subdomain, or only keep the modes that have X amount of overlap with some spatial region automatically (an example might be enough)

Would be especially useful to deal with PML modes

@HelgeGehring @mdecea

[HelgeGehring]

totally agree!

maybe already the recently added n_guess parameter in solve_modes helps (if you put in the n_eff of a straight waveguide)

[HelgeGehring]

But longterm I really want that, what's missing before I can start implementing it:

• A way to define the subdomain, can we somehow add a subdomain, which includes some stuff which is in other subdomains? I.e. keep the material subdomains, but add a "mode solving" domain?
• Maybe we can do this on the skfem level? I.e. pass as elements a function which takes all elements with a certain distance to a subdomain?

Probably it'd be good to have both options?

[HelgeGehring]

Besides that: for PML modes you need to include the PML in the modesolving ;)

[simbilod]

Besides that: for PML modes you need to include the PML in the modesolving ;)

Yes that's why I think instead of subdomains it's even better to keep modes based on the overlap integral with some region of space

So in the PML example you mode solve with the PMLs, and get a lot of PML modes that don't overlap with the waveguides (so the overlap integral is small), and they can be automatically rejected

[HelgeGehring]

maybe the cleanest quick way is to use the confinement factor, see end of https://helgegehring.github.io/femwell/photonics/examples/waveguide_modes.html

Just calculate it for all returned modes and reject everything below 20% or something

[HelgeGehring]

The more I think about it the more I think it's the cleanest way at all - but still, calculate the n_eff of a straight waveguide and use it as a n_guess to avoid the need of calculating may modes

[simbilod]

The more I think about it the more I think it's the cleanest way at all - but still, calculate the n_eff of a straight waveguide and use it as a n_guess to avoid the need of calculating may modes

Yep that's always a good starting point

[simbilod]

This was addressed by #37 right?

[HelgeGehring]

I think originally the idea was to just solve the mode on a subdomain. But as this would lead to errors due to closer boundaries I'd guess we can close this as we have several working ways :)

[mdecea]

I agree that we have several working ways, but having it solve on a subdomain would be very useful.

The problem with the current approach is that you might need to solve for a large number of modes to find the mode you are interested in (for example, in some SiN + Si simulations I need to go up to 7 total modes!). This increases significantly the execution time.

Maybe an easy workaround for the closer boundaries would be to select only the elements within an ROI and then expand the resulting simulation region with a constant refractive index so that the dimensions are maintained?

[HelgeGehring]

Okay, reopening!

Hmm, I'd guess we should keep the surrounding elements the same and just cutoff things which are too far away, right?

Another approach could be to once run a simulation with the other waveguide set to "environment" and then use the effective refractive index as a guess?