Interfacial components

[simbilod]

See issue 1067 in gdsfactory

How easy would it be for sax.circuit to also account for interfaces between components?

I am thinking a flag that, if True,
(1) requires the user to provide models for component pairs that show up connected in the graph
(2) adds a component evaluating these models at every "connection" of the netlist

The obvious use case is to model reflections in direct transitions between waveguides with different widths or bend radii. Currently gdsfactory+SAX throws a critical warning for the former, and evaluates the second without mode mismatch reflections.

Maybe this should be added as an option in gdsfactory.get_netlist()?

Example of desired behaviour for bend --> coupler --> straight :

Input:
circuit, _ = sax.circuit(c.get_netlist(), models=models, interfaces=True)
Output:

"Given Models": [],
"Required Models": ["bend_circular", "coupler_full", "straight"],
"Required Interface Models": [("bend_circular:o2", "coupler_full:o1"), ("coupler_full:o3", "straight:o1")],

If there were open-source EMEs around the required reflection matrices would be very easy to calculate :)

[flaport]

Thanks Simon,

I agree that that would make EME simulations easier.

That said, maybe this is something we can do by just patching the netlist? An interface can also be seen as a length-0 2-port (one input, one output) component and hence we could patch certain connections in the netlist by patching these 0-length component models in. I am more of the opinion that connections within sax should remain purely logical.

That said, if other people think differently about this, I'd be open to work on this (or accept a PR 😉).

@simbilod
@joamatab
@tvt173

---

To come back to the error you copied in above... it seems that this is unrelated to the issue at hand. The issue here is that no models for 'bend_circular', 'coupler_full' and 'straight' were given to the circuit factory... (it's hard to tell what exactly went wrong without seeing the full models dictionary)

scrap that, I just re-read your issue and it's clear to me that this is a proposed way of handling interface models. Honestly I think it's quite clean and could be worth implementing.

[simbilod]

Yep at the calculation level patching the netlist is definitely the way to go, especially since as you say the impact of interfaces shows up as non-unity transmission of 1-port in, 1-port out components that don't change the graph

My main question for everyone is if it's better to:

(1) artificially add these "interface" components in gdsfactory when extracting the netlist, and then treating interfaces as regular models when calling SAX

or

(2) building this option into SAX circuits directly, adding this new type of "interfacial models"

I edited my comment to make the "desired behaviour" example clearer :) It also seems that the interfaces would probably need to be defined on a component:port basis, and not just component, for instance as "component_name:port_name" :

"Required Interface Models": [("bend_circular:o2", "coupler_full:o1"), ("coupler_full:o3", "straight:o1")],

[flaport]

I think it might be worth implementing this in SAX directly.

I think a slightly cleaner api would be to always optionally accept interface models. If interface models are given, those models are patched into the netlist. If no interface models are given a 100% transmission is assumed.

This might potentially also help with resolving routes in the netlist yaml in a pretty clean way.

[simbilod]

Sounds good, I can take a stab later this week

Maybe we can call them "connection models" to keep with the existing SAX terminology of instances + connections

[flaport]

I like the idea of calling them connection models.

Sounds good. I'll let you take on this issue. Let me know if you need any help.

[cdaunt]

Hi

Correct me if I am wrong but s-parameters can only be defined once the port reperences are known. Typically in RF world, this is the "reference impedance" or $Z_0$ and the reflections at interfaces automatically drop out once s-parameters are renormalized to a common referenence (for example).

The "photonic" equivalent I guess would be the reference mode $n_{eff}$ for which the rest of the circuit should be renormalized to. The same math drops out if one looks at the known reflection terms in each domain

$\Gamma = S_{11} = \frac{Z_L - Z_0}{Z_L + Z_0}$
vs
$$R = \left( \frac{n_{eff,1} - n_2}{n_{eff,1} + n_2} \right)^2$$

In additon to the reflection, there is loss from mode mismatch which is typically neglected in the RF domain but does need to be accounted for in the optical domain.

Simulating in a common reference impedance is pretty straight forward in SAX if all components have the reference impedance as a parameter and can be passed down to each component effectively normalizing everything to a common impedance however this is commonly neglected in photonics.

The issue I see here is the current s-paraemeter descriptions do not specify a reference (whether $Z_0$ or $n_{eff}$). I am not sure if it should be included in SDict but there should be some equivalent to the $z_0$ attribute in scikit-rf.Network. To solve the above, it may make sense to account for the renormalization first and then add in the mismatch terms.... I just don't know how I would go about it in the decriptions though.

[nikosavola]

Hi

Correct me if I am wrong but s-parameters can only be defined once the port reperences are known. Typically in RF world, this is the "reference impedance" or Z 0 and the reflections at interfaces automatically drop out once s-parameters are renormalized to a common referenence (for example).

The "photonic" equivalent I guess would be the reference mode n e f f for which the rest of the circuit should be renormalized to. The same math drops out if one looks at the known reflection terms in each domain

Γ = S 11 = Z L − Z 0 Z L + Z 0 vs R = ( n e f f , 1 − n 2 n e f f , 1 + n 2 ) 2

In additon to the reflection, there is loss from mode mismatch which is typically neglected in the RF domain but does need to be accounted for in the optical domain.

Simulating in a common reference impedance is pretty straight forward in SAX if all components have the reference impedance as a parameter and can be passed down to each component effectively normalizing everything to a common impedance however this is commonly neglected in photonics.

The issue I see here is the current s-paraemeter descriptions do not specify a reference (whether Z 0 or n e f f ). I am not sure if it should be included in SDict but there should be some equivalent to the z 0 attribute in scikit-rf.Network. To solve the above, it may make sense to account for the renormalization first and then add in the mismatch terms.... I just don't know how I would go about it in the decriptions though.

Thanks for the great write-up. I added a z0 parameter to some of the recent RF models in
https://github.com/flaport/sax/blob/362c969a7aaf4251738e8bce497da5b8ee854168/src/sax/models/rf.py. These were motivated by https://github.com/gdsfactory/quantum-rf-pdk. It would be nice to handle the normalization in a smart manner in Sax to avoid any confusion.