Add lumerical CHARGE integration

[elamdf]

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

• allow users to specify the charge solver region, contacts, and bias sweep
• copy over geometry + dopings from the GDSFactory design
• output/return a (3d for now, could add 2d functionality later) charge distribution that can be imported into FDTD

[simbilod]

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

[elamdf]

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

[simbilod]

Good luck! You might also want to look at photonflux: https://github.com/alexsludds/photonflux

[thanojo]

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 ProcessSteps (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,

• The latter function could then be called by more user-faced functions like the existing write_sparameters_lumerical or @elamdf 's write_charge_distribution_lumerical.
• Extracting modes (including export to INTERCONNECT) or setting up EME simulations is easily achieved, and I could add a framework for that too, in a style matching the existing gplugins mode solver integrations.
• CHARGE, HEAT & MQW simulations could also be achieved.

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:

• Should a new issue be created for this?
• Should I fork from @elamdf 's work or merge their commits into a new fork from the main repo?

Cheers:)