Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Unified geometry interface for simulation components

Aperta
  • Qualcosa non va?
#139 16 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Read the draft at gplugins/tidy3d/base.py and the related issues #119, #121, #122, and #131 to understand the proposed shared interface; the payload also points to the tidy3d implementation in PR #239. The scope is to agree on and implement a common geometry interface across simulators, with decisions needed around immutability, ports, materials, and visualization. The issue does not define a bounded completion criterion, and its last comment was 987 days ago.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement help wanted

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.

@joamatab @nikosavola @simbilod @HelgeGehring @mdecea

Lingua principale
Python
Stelle
62
Fork
66
Merge medio
1g 15h
PR unite (30g)
12

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di gdsfactory/gplugins

Tutte le issue di gdsfactory/gplugins

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.