issue about Boolean operation: difference

[HoneyGump]

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")

[HelgeGehring]

Thanks for the bug report!

I further simplified the example, the problem is already visible without applying difference() (as lines into the waveguide):

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

cell = Cell('cell_difference')
cell.add_to_layer(1, Spiral(origin=(0, 0), angle=0, width=0.45, num=1, gap=3, inner_gap=30))
cell.save('issue_23.gds')

Already changes like angle=1 make it dissapear, therefore, it seems related to rounding errors. It seems to appear when subsequent segments of the waveguides are not exactly overlaping at the port. Furthermore, the two lines seem to be caused by different reasons. One I could fix in 2c69d33f4ac3ccd00cd6a83582fe3021ab3c1644 by adding the path_derivative to add_straight_segment.

The second line is exactly at the port between add_parameterized_path and the straight part of add_route_single_circle_to_port, but I didn't find yet the exact origin of that line.

As a workaround, your example can be fixed by device = geometric_union([spiral]).buffer(1e-12). I'd guess something similar is done in the boolean function of gdspy.

[HoneyGump]

Thanks for gdshelpers and your share again. This package is far more powerful than the document says.

Just now, I found this function gdshelpers.helpers.positive_resist.convert_to_positive_resist() did exactly what I wanted. My issue had been noted and fixed in the codes of the above function, which is the same as what you told me above.

# Sometimes those polygons do not touch correctly and have micro gaps due to
# floating point precision. We work around this by inflating the object a tiny bit.
fixed_union = union.buffer(np.finfo(np.float32).eps, resolution=0)

This function is very useful and convenient, and I recommend you give an example code in the tutorial, title could be just like from negative layout to postive layout.

one negligible request

It could be better, If this function can operate gds format file directly and correctly, not only Parts object. I know this is very difficult to obtain the outline of layout for buffer and difference. Some other packages achieve it by a bigger rectangle region 'minus' the layout directly. The layout from this method could cause huge waste of money and time.

At the end, thanks your immediate response.

[HelgeGehring]

Nice to hear that you like the package! Okay, I forgot that it's already handled there, I'd guess then we can consider this problem as solved. Yeah, the documentation is always lagging a bit behind the source code :/ @ThomasGrottke could you add something about gdshelpers.helpers.positive_resist.convert_to_positive_resist?

How exactly do you mean it? Do you want to read in a gds-file (There's already a not yet documented part for that) or do you mean to take a rectangle instead of the buffer to avoid some calculations? In the latter case, I'd guess ebeam-time is more expensive than cpu-time and therefore, I'd prefer the current solution.

[HoneyGump]

I'm sorry that the above requset comfused you. I want to read in a gds-file and and convert it to positve layout for postive resist.