Unified geometry interface for simulation components

[yaugenst]

Is your feature request related to a problem? Please describe. Currently, most device simulators derive their simulation properties (in particular geometries) from a patchwork of logic, e.g. from functionality contained in gdsfactory proper, from other gplugins, and self-implemented ones. This leads to a duplication of efforts and makes things harder to maintain.

Describe the solution you'd like Ideally, there should be a single "source of truth" when it comes to simulated geometries. This could be implemented as a component base class that combines a layerstack and a component (and whatever else might be necessary that I'm not aware of currently) and provides a single interface from which all relevant attributes can be extracted easily. Developers could then implement whatever additional logic is necessary for a particular simulator on top of this interface.

I have implemented a draft of this base component in the tidy3d plugin rework (WIP) in #138 (see here). It's currently very incomplete and I've submitted it mostly because I am seeing a lot of issues crop up recently along similar lines (e.g. #119, #121, #122, #131) that could all be addressed with a common interface and I think it would be good to have a discussion.

Some considerations:

• Immutability: A simulation component should be immutable. It is derived from a particular layerstack and device, and if any of that information changes, it should be considered a new component.
• Owing to immutability, a component class should be hashable (implemented). This makes it easy to identify components for e.g. caching of simulation results for particular components or comparisons.
• The base component should have a fixed interface (allow_extra=False) to provide a strong guarantee of what is and isn't provided by this class. Children should modify their own behavior as needed.
• Ports: Since components have ports (usually), the component base should be able to provide information on port placement and sizing. I have started to implement this, and especially port sizing can (and probably should) be automated, i.e. I think one should be able to just ask the simulation component for the port sizes and it should provide them while handling spacing between ports and simulation boundaries automatically.
• Material properties: I am undecided whether this should be done in the base component or in the derived components that different simulators use. Probably the latter because material definitions differ greatly between different simulators.
• Visualization: Since all the geometry information is already contained in the component, there should be a way to visualize the component independent of different simulators. I have plotting implemented for the derived tidy3d component, but ideally this should live in the component base.

Long term this would enable us to add new simulators with relative ease and add new functionalities to existing ones, e.g. fabrication corner analysis is something that can simply extend the functionality of a base component (either via direct implementation or mix-ins) with little to no changes required to existing simulators (that already use the SimulationComponentBase)

If you agree that this is something that we should try to pursue, then it would be good to have a discussion on the actual interface that this component should provide. The one I've implemented is relatively bare-bones. It implements everything that's needed for tidy3d simulations, so there are very likely to be things that I've missed.

• [x] tidy3d https://github.com/gdsfactory/gplugins/pull/239
• [ ] meep
• [ ] fdtdz
• [ ] lumerical @seanlam97

@joamatab @nikosavola @simbilod @HelgeGehring @mdecea