Open elamdf opened 7 months ago
there is a poorly-documented Synopsys Process + Device integration on a branch over here: https://github.com/simbilod/gplugins/tree/sentaurus, see files https://github.com/simbilod/gplugins/tree/sentaurus/gplugins/sentaurus
Works in 2D and 3D
It uses the Component + LayerStack, in addition to a Process definition as per https://github.com/gdsfactory/gdsfactory/blob/main/gdsfactory/technology/processes.py, see generic process example at https://github.com/gdsfactory/gdsfactory/blob/a424225f3d1d1a7c8a53c1da58f95a941026dad2/gdsfactory/generic_tech/layer_stack.py#L287
The svisual integration can parse the charge densities and export them, I`ve been successfully perturbing femwell mode profiles with it
seems like it won't be too different from FDTD- working on it over here. Would like to eventually have some easy way to get sparams for an active device under a sweep of voltage biases
Good luck! You might also want to look at photonflux: https://github.com/alexsludds/photonflux
Dear all,
I'd be excited to also contribute to this, and would also like to help integrating Lumerical MODE.
For me initally, obtaining 'bare' physically accurate 3D models in DEVICE, FDTD & MODE from gds would be the focus, also for III-V materials systems (i.e. without solvers, simulation regions, boundary conditions, etc.). The setting-up, running & analysis of simulations, e.g. Sparameter-extraction, would follow later.
An important first step would probably be to leverage the already quite capable Lumerical lbr file format and the Lumerical layer builder as an alternative to the traditional gdsimport
. It can include doping and specific material definitions. Similar to how a Klayout lyd25 script can be dynamically generated from the gdsfactory LayerStack
or a Process definition with gdsfactory.technology.processes
ProcessStep
s (as mentioned by @simbilod), it is hoped that something similar can be achieved for the lbr file (That said, lbr is not as powerful as lyd25, let alone sentaurus, for process definitions).
It could involve things like
def write_process_file_lumerical(layer_stack: LayerStack,
dirpath: PathType | None = None, str,
...):
...
'''This can be done with or without actually running Lumerical, though in the latter case only strings can be set as material models (e.g. better when default material database is used)'''
...
def build_model_lumerical(component: ComponentSpec,
session: object | str = 'DEVICE',
layer_stack: LayerStack | None = None,
... ):
...
session = lumapi.opensession(session) if isinstance(session, str) else session
...
return session
which would either generate an lbr file or use an existing one to build a lumerical model. They could be added as methods to @Elamdf 's Lumerical
class.
With this in place,
write_sparameters_lumerical
or @elamdf 's write_charge_distribution_lumerical
.Let me know if this sounds good to you. Being somewhat new to open-source developement, if I were to proceed, I'd have some questions:
Cheers:)
Is your feature request related to a problem? Please describe. Being able to end-to-end simulate active electronic-photonic devices designed in GDSFactory (such as PN phase shifters) in lumerical would be very attractive to those designing them.
Describe the solution you'd like One potential implementation of a Lumerical CHARGE integration would