Interface for writing plugins

[yaugenst]

We should define a common interface for writing gdsfactory plugins. Plugin interfaces will be defined via gplugins/common/base_models, with common pydantic base models that plugins can derive from.
Obviously we cannot cover every possible plugin, but there is definitely some common ground that we should be able to cover.
Base types should only cover types that are (possibly) common to all plugins and have no dependencies on other plugins, custom types for specific plugins should be defined inside of that particular plugin. Feel free to add whatever I might have missed @simbilod @joamatab.

Todos:

• Add types for common interfaces:
  • Component / Geometry
  • Ports
  • Simulation
    • Results
    • Modes (if applicable)
    • S-parameters (if applicable)
  • Materials
  • I/O & logging
  • Plotting (?)
• Refactor existing types to respect the new hierarchy #144
• Add documentation for plugin developers

[simbilod]

Given standardized definitions for these types that include inputs and outputs, do you think standardized ways to interpolate within the space of LayeredComponentBase inputs (the hashed Layerstack and Component) can also belong here?

I had toyed with the idea a while back with a Model class that was subclassed by the various plugins to provide a standard way to interpolate, broadly-defined (generate a set of input vectors, calculate the corresponding output vectors by calling the children class, and generating some callable that can give you new output vectors from new input vectors). See:
https://gdsfactory.github.io/gplugins/notebooks/sax_02_model_extraction.html
https://gdsfactory.github.io/gplugins/notebooks/sax_03_variability_analysis.html

But it was very much a prototype. Does that even make sense? To go from a device simulation to a circuit simulation this can be powerful.

[joamatab]

@flaport
@lucas-flexcompute
@nikosavola

[yaugenst]

Given standardized definitions for these types that include inputs and outputs, do you think standardized ways to interpolate within the space of LayeredComponentBase inputs (the hashed Layerstack and Component) can also belong here?

Hmm I think these are likely two separate issues. I think our main goal should be standardizing inputs and outputs, these are the types that we are targeting. For things like S-parameters it's relatively obvious how to do that, so probably we should do that first. Once there are a few simulation plugins that support these standardized types, it will hopefully be trivial to just chain them together. In principle this is not something that we need to take explicit care of but that should "just work", it's just function composition then.

Creating interpolating models from that I think is a separate issue and it might more sense to have that in a separate plugin. From the notebooks you linked I think something like Kriging really is a natural fit, and of course it might make sense to have different interpolators too. But that is a lot of functionality that I'm not sure should be supported in a common core. What do you think?

[drinwater]

Is there a reason for not using ComponentSpec, Ports from gf.typings?

-SkandanC

[yaugenst]

Is there a reason for not using ComponentSpec, Ports from gf.typings?

Hey @drinwater, not sure what you mean? Both gf.Port and gf.Component are being used or referenced. LayeredComponentBase depends on these as well as a LayerStack to derive information about the geometry, but they are not interchangeable.

Some of the functionality should probably make it upstream to gdsfactory, e.g. the serializable GFComponent defined here, but not in the hacky state that it is currently in (i.e., we should think about supporting proper serialization and deserialization of these objects).

[drinwater]

I meant as types for Components, and Ports

[yaugenst]

I'm still not sure what you mean, are you referring to the semantic difference between importing gf.Component vs gf.typings.Component? Those are functionally equivalent. It would make sense if we were using any of the compound types defined in gf.typings, but we don't (currently).

[github-actions]

This issue is stale because it has been inactive for 60 days. Remove stale label or comment or this will be closed in 7 days.