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.