How can we simplify the installation process?

Options

• executable window anaconda on packager. Ship anaconda environment, use constructor to create a conda installer, or mambstructor for mamba

@tvt173 @HelgeGehring @simbilod @flaport @thomasdorch

It would be nice to extend gmeep's capabilities to include Meep's adjoint optimization features. This way, we can optimize some of gdsfactory's primitive components such as mmi1x2, generate a gdsfactory component from them, and eventually gds files.

Things to do:

• [x] Figure out how to setup a Meep adjoint optimization simulation from gdsfactory components
• [x] Figure out how to extract a gdsfactory Component object, and eventually a gds file, from the PNG files generated by Meep

For the latter, we can convert the PNG's to a numpy array, and then use gf.read.from_np to generate a gdsfactory component, as per @joamatab's suggestion. Or, if there's a way to create gds files straight from Meep, we can just turn those into a gdsfactory component.

"""FIXME.


"""
import numpy as np
import matplotlib.pyplot as plt
import jax.numpy as jnp
import sax
import gdsfactory as gf


def straight(wl=1.5, length=10.0, neff=2.4) -> sax.SDict:
    return sax.reciprocal({("o1", "o2"): jnp.exp(2j * jnp.pi * neff * length / wl)})


def mmi1x2() -> sax.SDict:
    """Returns an ideal 1x2 splitter."""
    return sax.reciprocal(
        {
            ("o1", "o2"): 0.5**0.5,
            ("o1", "o3"): 0.5**0.5,
        }
    )


def mmi2x2(*, coupling: float = 0.5) -> sax.SDict:
    """Returns an ideal 2x2 splitter.

    Args:
        coupling: power coupling coefficient.
    """
    kappa = coupling**0.5
    tau = (1 - coupling) ** 0.5
    return sax.reciprocal(
        {
            ("o1", "o4"): tau,
            ("o1", "o3"): 1j * kappa,
            ("o2", "o4"): 1j * kappa,
            ("o2", "o3"): tau,
        }
    )


def bend_euler(wl: float = 1.5, length: float = 20.0, loss: float = 50e-3) -> sax.SDict:
    """Returns bend Sparameters."""
    amplitude = jnp.asarray(10 ** (-loss * length / 20), dtype=complex)
    return {k: amplitude * v for k, v in straight(wl=wl, length=length).items()}


def phase_shifter(
    wl: float = 1.55,
    neff: float = 2.34,
    voltage: float = 0,
    length: float = 10,
    loss: float = 0.0,
) -> sax.SDict:
    """Returns simple phase shifter model.

    Args:
        wl: wavelength in um.
        neff: effective index.
        voltage: voltage per PI phase shift.
        length: in um.
        loss: in dB.
    """
    deltaphi = voltage * jnp.pi
    phase = 2 * jnp.pi * neff * length / wl + deltaphi
    amplitude = jnp.asarray(10 ** (-loss * length / 20), dtype=complex)
    transmission = amplitude * jnp.exp(1j * phase)
    return sax.reciprocal(
        {
            ("o1", "o2"): transmission,
        }
    )


models = {
    "bend_euler": bend_euler,
    "mmi1x2": mmi1x2,
    "mmi2x2": mmi2x2,
    "straight": straight,
    "taper": straight,
    "straight_heater_metal_undercut": phase_shifter,
    "compass": sax.models.passthru(10),
    "via": sax.models.passthru(10),
}


if __name__ == "__main__":
    c = gf.components.switch_tree(bend_s=None)
    c.show(show_ports=True)
    n = netlist = c.get_netlist_recursive(
        exclude_port_types=("electrical", "placement")
    )
    # netlist.pop(list(n.keys())[0])
    mzi_circuit, _ = sax.circuit(netlist=netlist, models=models)
    S = mzi_circuit(wl=1.55)
    wl = np.linspace(1.5, 1.6, 256)
    S = mzi_circuit(wl=wl)

    plt.figure(figsize=(14, 4))
    plt.title("MZI")

    plt.plot(1e3 * wl, jnp.abs(S["o1_0_0", "o2_1_9"]) ** 2)
    plt.plot(1e3 * wl, jnp.abs(S["o1_0_0", "o3_1_6"]) ** 2)
    plt.plot(1e3 * wl, jnp.abs(S["o1_0_0", "o2_1_5"]) ** 2)
    plt.plot(1e3 * wl, jnp.abs(S["o1_0_0", "o3_1_10"]) ** 2)
    plt.xlabel("λ [nm]")
    plt.ylabel("T")
    plt.grid(True)
    plt.show()

How can we make schematic capture of the circuits?

we currently support netlist flow

it would be great to support something like this for analog design flow

some functions, like meep and tidy3d write sparameters assume the o1, o2, o3 ... port names.it would be great to enable other port naming conventions.

Here are some other port conventions

• Siepic pdk uses opt1, opt2, opt3
• IPKISS2 uses E0, W0, N0, N1
• IPKISS3 uses in0, in1, out1, out0

gdsfactory is built on top of gdspy

The main issues are:

• extra dependencies makes the package harder to install and sometimes hard to follow and document
• gdspy is no longer developed (only in maintenance mode). gdstk is supposed to be the successor of gdspy
• gdspy requires conda install for windows. Now you can install gdsfactory through mamba/conda but it would be nice to only depend on one package manager such as pip

We have some options

1. switch to klayout API

• Klayout has faster booleans
• Klayout builds wheels for windows pip install klayout. So no more need to conda install gdsfactory for windows users.
• Klayout is already an optional dependency
• Klayout API is not super well documented

See @amccaugh work on the phidl klayout backed @sebastian-goeldi @thomaslima

See zeropdk

2. switch to gdstk

• gdstk is an improved version of gdspy

3. switch to rust

https://github.com/dan-fritchman/Layout21/

What do you think?

@thomasdorch @tvt173 @flaport @basnijholt

Can call MEOW directly on component + layerstack to get single-wavelength Sparameters from EME

• Converts gdsfactory LayerStack to MEOW extrusion rules
• Converts gdsfactory materials to MEOW material
• Converts MEOW output S-parameter format to gdsfactory S-parameter format
• Validates component, currently can only simulate 2-ports components with west and east-facing ports
• Documentation notebook showing simple calls

We can now use gdsfactory generic pdk (or any other pdk derived from it), straight in KLayout.

Major stuff:

• Combined link_gdsfactory_python and import_generic_pcells.
• Added a class to turn gdsfactory Components to Klayout PCells
• Progress bar to show component loading progress
• Fix bug preventing update of PCells without changing name - This was an issue on gdsfactory's side, doing gf.clear_cache() fixed it

Things to improve:

• Flayout does not support tuple of floats as parameters for the PCells, so such Component arguments cannot be modified
• Same as above with CrossSectio, ComponentType and other such types

Describe the bug There is an installation error for gdspy package. This is how it looks like when you install it -

To Reproduce I created a venv for both python3.7 and 3.8. Let me know you are able to reproduce the error using this method.

Expected behavior Clean installation

Suggested fix No idea

The size of the Mode monitor is not correctly taken into account for bends:

from gdsfactory.components import bend_euler
from gdsfactory.simulation.gmeep import write_sparameters_meep
from gdsfactory.simulation.effective_permittivity import calculate_effective_permittivity

bend = bend_euler(radius=5)
material_name_to_meep = {
    'si': float(calculate_effective_permittivity(3.477 ** 2, 1.444 ** 2, 1.444 ** 2, .22, 1.55, 'te')[0] ** .5)}
write_sparameters_meep(bend, resolution=20, is_3d=False, animate=True, material_name_to_meep=material_name_to_meep)

Is it normal for 2D Meep simulations to be much slower to initialize than to actually run? I have been using the conda-forge Meep package with MPICH and write_sparameters_meep_mpi can take upwards of 5-10 minutes to initialize and perform subpixel averaging on a simulation domain of 20 x 10 at 30-40 resolution using 24 threads, but the simulation itself only takes maybe 30 seconds to a minute.

If this is normal, is there anything we can do to speed up this part of the simulation?

Bumps tidy3d-beta from 1.8.0 to 1.8.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

In Tidy3D 1.8.0 we introduced FieldData.dot(other_data) and ModeSolverData.dot(other_data) methods to correctly compute overlaps between two sets of mode data from the mode solver or field data from the FDTD solver. One thing that this does better compared to the current implementation in the gdsfactory Tidy3D plugin is that the fields are spatially colocated to the same positions (the centers of the Yee grid), while in the plugin the raw fields are used, which live on the Yee grid.

This return should then use the natively supported dot method. Also, modes are now normalized coming out of the solver, so this is not needed (the abs value can be put e.g. in the return statement if this is entirely removed, e.g. return r, np.abs(integral)**2.

However, looking through the tidy3d mode plugin, I see that it utilizes our low-level compute_modes function directly, instead of our mode solver. The fields that come out of those are not packaged in a ModeSolverData and they are not normalized, so this would be more work than I thought. I see two possible approaches:

• Rewrite the gdsfactory plugin to use the tidy3d ModeSolver directly rather than the lower-level compute_modes function. If needed, we could add a way for the ModeSolver to use arrays of n, k as opposed to structures + a mode plane, but I don't see why this would be needed. If the Tidy3D solver plugin doesn't need to use those, it should be possible to use the mode solver just through structure definitions too. So I think this is the preferred approach.
• Keep the current compute_modes usage but create a ModeSolverData with normalized modes out of the output fields. This would seem to require porting some of the tidy3d ModeSolver code to the plugin here, which doesn't make that much sense to me.

@joamatab has mentioned that this loss computation seems too good to be true, hopefully this will fix this but it will be good to see.

@lucas-flexcompute maybe you could have a look at this when you find some time?

Addresses #1054 #653

Work in progress on automating N-D input to M-D output S-parameter interpolation for circuit and variability simulations. Feedback welcomed!

Currently only the EME sub-simulator is interfaced, but most of the work is done in a generic parent class.

Usage is designed to be very simple: (1) user parametrizes a Component, and provides a LayerStack (2) user calls a child of the Model class, specifying simulation parameters and which parameters are swept across what range. Parameters can be Component arguments, LayerStack thicknesses, and others (like wavelength is simulation depends on it) (3) simulations are run and an interpolator is returned that can give S-parameters within the ND input range

Example:

    import gdsfactory as gf
    from gdsfactory.cross_section import rib, strip
    from gdsfactory.simulation.sax.parameter import LayerStackThickness, NamedParameter
    from gdsfactory.tech import LayerStack

"""Define component"""

    c = gf.components.taper_cross_section_linear(
        cross_section1=rib(width=2), cross_section2=rib(width=0.5)
    )
    c.show()

"""Define LayerStack"""

    layerstack = gf.tech.get_layer_stack_generic()
    filtered_layerstack = LayerStack(
        layers={
            k: layerstack.layers[k]
            for k in (
                "slab90",
                "core",
                "box",
                "clad",
            )
        }
    )

"""Parametrize component: here, we fix one width, and make length and the other width changeable:"""

    trainable_strip_strip_taper = (
        lambda parameters: gf.components.taper_cross_section_linear(
            length=parameters["length"],
            cross_section1=strip(width=0.5),
            cross_section2=strip(width=parameters["width2"]),
        )
    )

"""Create a model object, which defines simulator to use and which variable to sweep and in what range"""
    strip_strip_taper_model = MeowEMEModel(
        component=trainable_strip_strip_taper,
        layerstack=filtered_layerstack,
        simulation_settings={
            "mode_res": 100,
            "cell_length": 0.5,
            "num_eme_modes": 4,
            "spacing_x": 1,
            "spacing_y": -3,
            "overwrite": False,
        },
        trainable_parameters={
            "length": NamedParameter(min_value=5, 
                                        max_value=6, 
                                        nominal_value=6, 
                                        step=1
                                        ),
            "width2": NamedParameter(
                min_value=1.0, 
                max_value=1.0, 
                nominal_value=1.0, 
                step=1.0
            ),
            "wavelength": NamedParameter(
                min_value=1.545, 
                max_value=1.555, 
                nominal_value=1.55, 
                step=0.005
            ),
            "core_thickness": LayerStackThickness(
                layerstack=filtered_layerstack,
                min_value=0.19,
                max_value=0.25,
                nominal_value=0.22,
                layername="core",
                step=0.3,
            ),
        },
        num_modes=2,
    )

"""Get the interpolator"""
    # input_vectors, output_vectors = strip_strip_taper_model.get_data()
    interpolator = strip_strip_taper_model.get_nd_nd_interp()

    import jax.numpy as jnp

"""Evaluate the interpolator"""
    params = jnp.stack(
        jnp.broadcast_arrays(
            jnp.asarray([6.0, 6.0, 6.0]),
            jnp.asarray([1.0, 1.0, 1.0]),
            jnp.asarray([1.55, 1.5, 1.55]),
            jnp.asarray([0.22, 0.22, 0.19]),
        ),
        0,
    )
    print(interpolator["[email protected],[email protected]"](params))

Output:

Getting examples: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 6/6 [00:00<00:00,  6.61it/s]

[0.9993654+2.4627744e-25j 0.9993654-2.4463871e-25j
 0.9993654+2.4627744e-25j]

TODO:

• [ ] Wrap the interpolator in a Dict to make its inputs directly compatible with SAX SDicts
• [ ] More consistent use of JAX/JIT
• [ ] Add tests
• [ ] Add waveguide sub-simulator for interpolation
• [ ] Add 2.5D FDTD sub-simulator for interpolation
• [ ] Show JAX differentiability
• [ ] Notebook example
• [ ] Nice GIF showing component optimization at circuit level

Maybe:

• [ ] Neural net interpolation (I've made it work, but it requires lots of simulations, does not seem worth it over NDinterp so far)
• [ ] Neural net interpolation for optical modes like EMEpy, could speed EME up

Things that would be great to finish by the end of the Photonics West conference in San Francisco at the end of January

Design

• [ ] Fix klayout backend and compare with gdstk #1031
• [ ] Convert YAML netlist to spice #681
• [ ] Add generators for photonic components (taper, grating coupler, MMIs …)
• [ ] Define test sequence for lab measurements (validation)
• [ ] Fit simulations to build circuit models (coupler, waveguide …)
• [ ] Extend simulators to support Analog design (spice) and RF quantum workflows.
• [ ] Serialize GDS files to YAML (preserving hieararchy)

Verification

• [ ] LVS #934
• [ ] DFM Design for manufacturing. Simulate designs with erosion/dilation. Simulate devices after lithography (rounding effects)
• [ ] Yield estimation based on layout aware monte carlo simulations from erosion/dilation simulations

Validation

• [ ] Data analysis flow. Extract device parameters from measurements.
• [ ] Webapp for comparing simulations and measurements (correlation database)
• [ ] Add example scripts and documentation for deploying and using the database #992

@flaport @thomasdorch @SkandanC @simbilod @HelgeGehring @sebastian-goeldi @Jan-David-Black @proppy @mdecea @smartalech @damienbonneau @heitzmann @xin-flex @nikosavola @mithro

In #1048 I added an argument to flip the offsets of all sections in the pn cross-section

What would be the best place to add such a feature to generic cross-sections? Say, an argument in CrossSection that, if True, flips the signs of offset, all section offsets, all cladding_offsets, and all bbox_offsets?

CrossSection does not have a constructor where we could do this (it currently uses the BaseModel one). We could override that init and add the preprocessing there. Alternatively, if path.extrude is always called on cross-sections, maybe we could put it here. Does that cover all cases?

Pull Request #1014 refactored by Sourcery.

Since the original Pull Request was opened as a fork in a contributor's repository, we are unable to create a Pull Request branching from it.

To incorporate these changes, you can either:

1. Merge this Pull Request instead of the original, or

2. Ask your contributor to locally incorporate these commits and push them to the original Pull Request

   Incorporate changes via command line

   git fetch https://github.com/gdsfactory/gdsfactory pull/1014/head
   git merge --ff-only FETCH_HEAD
   git push

NOTE: As code is pushed to the original Pull Request, Sourcery will re-run and update (force-push) this Pull Request with new refactorings as necessary. If Sourcery finds no refactorings at any point, this Pull Request will be closed automatically.

See our documentation here.

Help us improve this pull request!