S-parameters bigger than one

[flaport]

Hi @hammy4815 , thanks for the nice library!

I was playing around with some custom cross sections and noticed that sometimes I'm getting S-parameters that are bigger than one!

I could distill the issue to a simple interface of two waveguides with different width (with ca custom cross section). As you can see in the jupyter notebook attached the resulting S-parameters for the mode transmission are bigger than 1.

Is this an issue with the mode normalization? mode overlap? interface s-matrix? I searched through the code to find any clues but I did not manage to find any.

I did a similar calculation with Lumerical EME and there the S-parameters all remain nicely smaller than 1.

Do you know what the issue can be?

Thanks

emepy_diverging.zip

[hammy4815]

Hi @flaport,

In the past, S-parameters greater than one typically imply the existence of spurious modes, either from a mesh that is not fine enough, or other reasons. More recently we were playing around with various ways to eliminate the spurious modes.

I can take a look this week at whether there are spurious modes or another issue going on and get back to you. Thanks for checking EMEPy out!

[flaport]

I don't think it's related to spurious modes though.. as you can see in the notebook I shared, I'm only considering 4 modes and all of them are guided modes and all 4 have a transmission larger than 1.

Anyway, thanks for looking into it 🙂

[hammy4815]

@flaport,

I have begun debugging your script. I tried changing the resolution and that did not seem to fix it. But I looked at the field profiles of the modes and they appeared to look like good propagating modes.

I did notice, however, that the solver seems to find a different mode set in the two waveguides. It finds the same first order modes, but the second order modes appear to be in different orders. But this shouldn't matter.

I have a lot of changes on another branch that I am currently porting over to main. One of these changes includes changing from absolute units to relative units. This will allow 1 to represent a micron and no longer require computation at orders of 1e-6. This should reduce any numerical error that might be happening.

I've also changed part of how my EME algorithm is implemented to help with more complex and custom mode injection for periodic and backwards devices. It also should help with running in parallel.

I am debugging the last of my hidden merge conflicts today and tomorrow and then I will try your notebook on the working new main branch with proper changes. I suspect it shouldn't have anything to do with the order that the modes are found since the s-matrix formulation EMEPy uses cares not for order. But I will further investigate. I suspect it may have to do with the way I am normalizing the phase actually. Your modes have a higher phase contrast across the field profile than I've used in previous devices.

We used Lumerical as a benchmark in the past for some simpler devices, so we would obviously like to match again for your device. I may have to play around with the boundary conditions for these modes. The default in EMEPy is not using PML at the moment. In the future once we have the PML working more properly it will be however.

In Lumerical for your simulation, which boundary conditions are you using?

[hammy4815]

Just another quick update, while debugging some of my recent algorithms I am pretty sure that the reason your simulation has these incorrect s params is because of the normalization.

The current overlap technique is phase dependent and relies on correctly normalizing the modes. I think I am going to play around with it and see if I can eliminate this dependence. Hopefully, it should fix your issue and some others I am having.

[flaport]

Thanks for looking into this @hammy4815 ! I'm using normal metal boundaries in Lumerical as well.

Here are a few things I figured out in the mean time:

• in stead of taking the center of the window to zero out the phase, you should take the center of the mode. You can find the maximum of the mode with something like this (np.argmax(np.abs(Hx)))
• sometimes the transmission matrix has exactly amount of gain (let's say 1.1) as you'd expect it to have loss (let's say 0.9). It seems like a terrible hack, but it seems to work very well for my usecase: you can invert the singular values of the transmission matrix T to obtain physical transmissions that are smaller than one. It's very strange, but it seems that gives the correct transmissions after all! I don't understand very well why this works, but at least empirically it seems to give the correct answers...

[hammy4815]

@flaport ,

This is certainly very interesting! Would you mind sharing your updated notebook so we could explore more what exactly is happening?

[flaport]

Here's an updated zip file. Please have a look. It contains an adapted version of the notebook and an equivalent lumerical.lms file.

emepy_diverging.zip

Let me know what you think.

[hammy4815]

Thanks @flaport . This is really helpful. I will dissect this problem this weekend to be sure what's happening and prevent future issues.

For the normalization, we are trying to create the best normalization scheme that covers phase and magnitude correctly for the EME overlap, for any boundary condition. Your method of choosing the mode center is certainly better than the window center as we were doing before, thanks for that.

As for the second part, I'm curious - what's your intuition for why you tried inverting the T matrix? Is there anything physical about this operation?

[flaport]

Hey @hammy4815 ,

the intuition just came from comparing with lumerical... I often saw exactly the amount of gain in stead of the loss Lumerical predicted.

That said, maybe the original T-matrix is showing gain because the modes are 'backward-propagating' modes? Hence any loss for a forward propagating mode is a gain for a backward propagating mode? I don't know if that even makes a lot of sense... I'm not so acquainted with the subject tbh. I'm also not sure how you could recognize these 'backward' modes or how you could invert them. Clearly it's kind of an empirical hack which seems to work quite well.

[hammy4815]

Hi @flaport ,

We're still not sure what inverting the matrix is doing in the last stage - but we have learned a few things while debugging. The source of the transmission greater than 1 is during the interface between the two mode sets (no surprise there). When looking at the system of equations that solves for the transmission values during the EME at the interface, transmission values greater than one can occur under a number of situations:

1. The inner product produces values greater than 1
2. The mode basis is not orthogonal
3. The mode basis provided is not enough to solve the system of equations with minimal error.

I verified that the first two are not happening in your device. The modes are plenty orthogonal and the inner products are all below 1, regardless of the way we normalize the phase.

We haven't actually encountered number 3 before now because our systems typically only allow a small number of well defined guided modes. But since rib waveguides support many modes, we think we may be underrepresenting the system of equations with two few modes.

We are currently seeing if using many modes can fix our problem. I know in Lumerical you only ask for a small number of modes, but Lumerical MODE also makes many approximations to speed up their algorithms. For example, if you only specify two modes it might be doing something clever to still produce somewhat accurate T values. (In the past we have learned that they for sure make clever tricks for single mode simulations). Our solver, however, is using a full system of equations that requires a large enough basis.

If this ends up being the source of error behind your example, the short term solution would be to just use more modes. Long term, there might be some tricks to add to EMEPy to either warn the user when this is happening or prevent it from happening.

So far, it seems like there are over 30 well defined modes that are found before any spurious modes. So there may even be more. I'll verify for sure if this is the issue. If not, we are going to look at a few other things.

Thanks!
Ian