Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mode solver neff jumps #113

Closed
KojaAMA opened this issue Dec 22, 2023 · 6 comments
Closed

mode solver neff jumps #113

KojaAMA opened this issue Dec 22, 2023 · 6 comments

Comments

@KojaAMA
Copy link

KojaAMA commented Dec 22, 2023

I encountered an issue when solving for 1st quasi TE&TM modes for different widths. The lines represents different widths. There are jumps in neff (flipping TE fraction). But if we follow the TE fraction guidance, the behavior is monotonic.

image
image

maybe somehow similar issue in the example https://helgegehring.github.io/femwell/photonics/examples/vary_width.html
image

@lucasgrjn
Copy link
Contributor

lucasgrjn commented Dec 22, 2023

Hi! By default, once calculated, the solver returns the modes by sorting them using the value of the $n_eff$. This is the reason why on the graph from the example , the line makes a jump between the two fractions when they cross.

Have you any code example you would like to share to discuss on it? :)

@HelgeGehring
Copy link
Owner

Hmm, we directly return the modes in the order eigs gives them to us.
Usually, that gives us a sorted set and everything's fine.
But I think in your example the spectrum is quite dense, which probably makes arpack find the eigenvectors in a different order 🤔

Solution: we maybe just sort them ourselves? The real part of the effective refractive index as the key?
As we won't find hundreds of modes, the extra time for that should be completely negligible?

@KojaAMA @lucasgrjn what do you think?

About the example in the docs: I think there is everything alright, as the modes cross they hybridize which leads to a splitting.
We should find some literature about that and explain it. Would someone have a good reference?

@DorisReiter

@KojaAMA
Copy link
Author

KojaAMA commented Dec 22, 2023

@HelgeGehring @lucasgrjn Thanks for the quick feedback.

Regarding the example: generally it seems that the solver finds the eigen number and vectors. But it would be helpful that the sorting works in a way to keep TE or TM fraction consistent since in most cases the interest is to get the quasi-polarization families and experimentally you want to excite one polarization. Maybe the work-around would be to enforce only finding either quasi-TE/TM families.

For my example: I will play around with the script and update you with it @lucasgrjn soon. Maybe sorting them ourselves @HelgeGehring would work ,I guess considering both neff & TE fraction might be a good option.

@HelgeGehring
Copy link
Owner

HelgeGehring commented Dec 22, 2023

I don't think it would be correct to keep the TE/TM fractions consistent as modes can hybridize, see for example

https://doi.org/10.1038/s41598-020-73936-x

Or what do you mean with consistent? I think it should look like in the example in the docs and have the continuous transitions between TE/TM for certain pairs of modes?

Experimental I do want to know where they hybridize as the system gets more complicated to describe (especially if we somehow break symmetry). If you keep your polarization constant, the light would at that point couple in both modes.
Usually, I think I wouldn't use those widths and couple in the hybridized modes except of I want to build a polarization rotator/splitter 🤔

Of course, we could solve simplified equations describing only TE or TM modes, but they would only be approximations and in the area of hybridization just be wrong.
@KojaAMA would you in your system expect the modes not to hybridize at all?

For sorting, modes = modes.sorted(key=lambda mode: -np.real(mode.n_eff)) should sort the modes like in the example and lead to continuous lines 🤔

@KojaAMA do I miss something? What system are you working on? Maybe I'm thinking too much of silicon/silicon nitride waveguides?

@KojaAMA
Copy link
Author

KojaAMA commented Dec 26, 2023

Thanks a lot for the paper, it was a nice read.
I was interested to get fun. quasi-TE/TM modes only. I guess those modes are hybrid but with dominant Ex/Ey components. I understood that the solver returns them sorted by highest neff but that in my case mixed the two sets. it worked for me now to sort them by TE fraction and I got what I was looking for. I think it is great that the solver finds strongly hybridized modes.

@HelgeGehring As far as I understand, the modes will be generally hybridized for most structures except infinite slab case. So I expect them to by hybrid modes in my ridge structure.

Thanks a lot for your help.

@HelgeGehring
Copy link
Owner

👍
I think that's also the reason to call them "quasi-"TE/TM, they have a dominant component, but the other component is non-zero.
As soon as you break certain symmetries, you cannot get pure TE/TM modes.
Besides the infinite slab you mentioned, rectangular RF waveguides with conducting surfaces (see https://www.everythingrf.com/tech-resources/waveguides-sizes) and perfectly symmetric optical fibers are I think other exampels of systems with pure TE/TM modes 🤔

The solver doesn't necessarily return them right now ordered by the neff. At the moment, we do not enforce a certain ordering, but just return whatever scipy's eigs gives us. As long as the spectrum is not too dense, they seem ordered, but once the spectrum gets dense, the ordering is not perfect.

Did you give it a try to just order by neff? I think that should also produce a nice graph for you and that way it should be perfectly robust.
I'd guess we should also include a .sorted(key=lambda mode: -np.real(mode.n_eff)) in the end of the compute_modes to not have those problems anymore?

Should we maybe explain the hybridization a bit in the example?

@KojaAMA KojaAMA closed this as completed Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants