https://github.com/HelgeGehring/gdshelpers/blob/96cfe541c18360dc8a8902fa723b7b5edfabbe72/gdshelpers/export/gdsii_export.py#L82-L84

So I am trying to implement 2 cells within a cell as an array. I am using the standard micron as the unit, but I am trying to have increased precision to 0.1nm [10000 grid steps per micron]. When I make the spacing equal micron steps apart, it works. When they are not, there is a spacing issue. I am pretty sure the problem is here in the code referenced above as internally the spacing kept in the gdspy_cell->references->spacing is correct. The code shown seems to round before the points are scaled by the grid_steps_per_unit rather than after, which I think is causing my problem.

Add method add_route_straight_to_port to Waveguide. Allows routing a straight segment to a target port and tapers the width linearly on the way.

This can be used for electrode contact pads etc.

Thanks for gdshelpers, this package is amazing!

When I used the boolean operation difference(), I got a small problem as shown in the figure, and it may occurr at the junction of the arc and the spiral. If I changed the parameter num, this issue would disapear. I don't know how to fix it. I tried to get the same layout by boolean operation not from gdspy package, and it looked correct.

The code is attached below.

from gdshelpers.geometry.chip import Cell
from gdshelpers.parts.spiral import Spiral
from gdshelpers.geometry import geometric_union

# create the spiral
spiral = Spiral(origin=(0,0), angle=0, width=0.45, num=16, gap=3, inner_gap=30)

# get the shapely 
device = geometric_union([spiral])
# Boolean operation: difference
buffer_device = device.buffer(3)
buffer_not_device = buffer_device.difference(device)

cell = Cell('cell_difference')
cell.add_to_layer(1, buffer_not_device)
# Here don't use cell.show() to verify the issue, and use cell.save() please.
cell.save('gdshelpers_difference.gds')


# And I found it's OK if I use "not" from gdspy.boolean()
from gdshelpers.geometry import convert_to_layout_objs
import gdspy
# STEP 1: 
lib = gdspy.GdsLibrary(precision = 1e-10)

# create a new cell to save 
cell_gdspy = lib.new_cell("cell_not_gdspy")

geo1 = convert_to_layout_objs(buffer_device,library='gdspy')
geo2 = convert_to_layout_objs(device,library='gdspy')
inv = gdspy.boolean(geo1, geo2, "not")

cell_gdspy.add(inv)
lib.write_gds("gdspy_not.gds")

This seems to be a regression, because I think it worked before, but the following produces an error:

wg = Waveguide([0, 0], 0, [1, 2, 1])
wg.add_parameterized_path(lambda t: [10*t, 10*t])
wg.get_shapely_object()

Error:

Traceback (most recent call last):
  File "gdshelpers/tests/test_waveguide.py", line 40, in test_waveguide_multiple_widths
    wg.add_parameterized_path(some_path)
  File "gdshelpers/parts/waveguide.py", line 275, in add_parameterized_path
    poly_path_1 = sample_coordinates + start[..., None] * sample_coordinates_d1_normed_ortho
ValueError: operands could not be broadcast together with shapes (3,1) (28,2) 

I opened a pull request which adds a failing test case: #26

Hi @HelgeGehring,

The first example script is flawed:

1. numpy is missing
2. Something is wrong with gdshelpers.parts.logo:

~/.local/lib/python3.7/site-packages/gdshelpers/parts/logo.py in get_shapely_object(self)
    180             # WWU width = 368.93 = 369     *M2 == w
    181             # box width unscaled = w = 336
--> 182             m2 = w / 369.  # scale width of WWU to width of logo
    183             m = self.height / (h + 10 + 114)  # scaling factor height
    184 

the code works with numpy and without logo:

import numpy as np
from gdshelpers.geometry.chip import Cell
from gdshelpers.parts.waveguide import Waveguide
from gdshelpers.parts.coupler import GratingCoupler
from gdshelpers.parts.resonator import RingResonator
from gdshelpers.parts.splitter import Splitter
#from gdshelpers.parts.logo import KITLogo, WWULogo
from gdshelpers.parts.optical_codes import QRCode
from gdshelpers.parts.text import Text
from gdshelpers.parts.marker import CrossMarker

# Generate a coupler with parameters from the coupler database
coupler1 = GratingCoupler.make_traditional_coupler_from_database([0, 0], 1, 'sn330', 1550)
coupler2 = GratingCoupler.make_traditional_coupler_from_database([150, 0], 1, 'sn330', 1550)

coupler1_desc = coupler1.get_description_text(side='left')
coupler2_desc = coupler2.get_description_text(side='right')

# And add a simple waveguide to it
wg1 = Waveguide.make_at_port(coupler1.port)
wg1.add_straight_segment(10)
wg1.add_bend(-np.pi/2, 10, final_width=1.5)

res = RingResonator.make_at_port(wg1.current_port, gap=0.1, radius=20,
                                 race_length=10, res_wg_width=0.5)

wg2 = Waveguide.make_at_port(res.port)
wg2.add_straight_segment(30)
splitter = Splitter.make_at_root_port(wg2.current_port, total_length=20, sep=10, wg_width_branches=1.0)

wg3 = Waveguide.make_at_port(splitter.right_branch_port)
wg3.add_route_single_circle_to_port(coupler2.port)

# Add a marker just for fun
marker = CrossMarker.make_traditional_paddle_markers(res.center_coordinates)

# The fancy stuff
#kit_logo = KITLogo([25, 0], 10)
#wwu_logo = WWULogo([100, 30], 30, 2)
qr_code = QRCode([25, -40], 'https://www.uni-muenster.de/Physik.PI/Pernice', 1.0)
dev_label = Text([100, 0], 10, 'A0', alignment='center-top')

# Create a Cell to hold the objects
cell = Cell('EXAMPLE')

# Convert parts to gdsCAD polygons
cell.add_to_layer(1, coupler1, wg1, res, wg2, splitter, wg3, coupler2)
#cell.add_to_layer(2, wwu_logo, kit_logo, qr_code, dev_label)
cell.add_to_layer(2, marker)
cell.add_to_layer(3, coupler1_desc, coupler2_desc)
cell.show()

best, quearitis

Since add_parameterized_path has no information about how the waveguide will proceed afterwards, it can be useful to set the last point in the list of derivatives.

Allows specifying clearance_features: useful when building e.g. DLW tapers with positive resist

When reusing cells (e.g. grating couplers on one cell) which have interfaces to other features the interface must not be covered with the positive resist but must remain open. This allows to specify exclusion zones at these interfaces.

changed line 283 from "...lower radii..." to "...larger radii..."

If the outer lines of a parameterized wg intersect, a larger radius or smaller wg must be used.

I ran into some out-of-memory errors when too many big cells where involved, limiting the number of workers can help (and might also help if you want to keep using your computer while exporting :) )

It would be helpful to have a small CONTRIBUTING.md in the root directory with the main instructions and conventions.

Especially the Flake8 flavor used, so people don't have to look it up in the CI script

flake8 gdshelpers/ --max-line-length=120

All route to port functions expect the target port to be pointing towards the current_port of the waveguide to be routed. This fixes add_route_straight_to_port to be consistent and adds a testcase.

If this is run on a cell array, it does not recognize multiple instantiations....only the original copy at the original origin is placed (like just cellarray[0] and not the others....). See the zip.zip file. Use the Top Cell for copy zip.zip

Sometime, the cell creation is expensive and benefits from parallelization. At the same time, some sub-cells can be reused between cells.

Currently, this fails because when ProcessPoolExecutor (or similar parallelization structures) are used, sub-cells are pickled and deserialized again. When merging the parallel cells together in the end, comparison for those sub-cells fails because they have no common identity anymore.

This adds a UUID when a cell is created, such that cells can be identified by their UUID.

Possible downside is that if a user modifies a sub-cell after it has been pickled, the changes might get lost, but this can easily be avoided by finishing the sub-cell before using it.

Suggestion for a new format for the desc output dictionary. This follows more closely the idea of GDSII that each cell is identified by a unique name and can be referenced mulitple times.

With this new format, the resulting dict will only contain the desc data for each cell once and just store (name) references to the other cells.

Basically, the resulting dict will look somewhat like this:

{
    "root": "name_of_root_cell",
    "cells": {
        "name_of_root_cell": {
            "desc": {...},
            "cells": [ <list of all cells referenced by this cell (with origin, angle etc.)>  ]
        },
        "other_cell": {
            "desc": {...},
            "cells": [ <list of all cells referenced by this cell (with origin, angle etc.)>  ]
        },
    }
}

This replaces the old spiral with a new version of an archimedean spiral which allows to set the length. The number of turns required to achieve the length is determined numerically (afaik an analytical solution doesn't exist).

Different types are supported. Especially for use inside an MZI the inline and inline_rel types are of interest.

ToDo's before merge:

• [ ] Update changelog
• [x] Add to tests
• [x] Update documentation
• [x] Allow choosing the spiral direction (752d3b2)
• [x] Choose an appropriate guess value for the numerical estimation