kfactory snapping issues about kgeneric

[tvt173]

@joamatab , i think your source code for the sample is mismatched with the sample shown in the image

[sebastian-goeldi]

Hm, yes this can cause issues. Can you check whether port and box of the waveguide and the port have the gap? I assume that's the prblem here.

You can dynamically toggle ports (created with kfactory) of the current top cell with this small klayout package here:

https://sami.klayout.org/preview?url=https%3A%2F%2Fgithub.com%2Fgdsfactory%2Fmetainfo-ports%2Ftags%2Fv0.0.3%2Fklayout

Alsp, stop using nm :D . You have c.kcl.dbu always available. And then you will see, this happens in case of non-integer multiple of dbu. In case of a box, meaning straight waveguide, you can make it resilient, but you'll notice that it's a bad idea to have devices that are not multiple dbu long, anyway. The way to go I see in this case is to just warn in case it's not a multiple of dbu. Because no matter what you want to do withit, you can't achieve it

[joamatab]

yes,

see the code here

import kfactory as kf

from kgeneric import gpdk as pdk

if __name__ == "__main__":
    c = kf.KCell("bend_chain")
    b1 = c << pdk.bend_euler_sc(angle=37)
    b2 = c << pdk.bend_euler_sc(angle=37)
    b2.connect("o1", b1.ports["o2"])
    # b1.flatten()
    # b2.flatten()
    c.flatten()
    c.show()

[SkandanC]

I recall we had a similar issue in kfactoiry and gdsafctiry before, disccussed here: snapping · Issue #150 · gdsfactory/kfactory (github.com)<gdsfactory/kfactory#150>. [https://opengraph.githubassets.com/203bf5177669561431eb933ee2d9163df316fe81afd806eaff064cdb7166e12d/gdsfactory/kfactory/issues/150]<https://github.com/gdsfactory/kfactory/issues/150> snapping · Issue #150 · gdsfactory/kfactory<gdsfactory/kfactory#150> Im trying to see if we can solve some of the issues here in kfactory gdsfactory/gdsfactory#1722 import kfactory as kf import numpy as np import kgeneric as kg import kgeneric.cells as kc @kf.cell(c... github.com Kf is still prone to snappong errors for non-manhattan connections, so ig the simole thing would just be to compute Paths and then extrude them.

…

________________________________ From: Joaquin Matres ***@***.***> Sent: Wednesday, August 16, 2023 1:52 AM To: gdsfactory/kgeneric ***@***.***> Cc: Skandan Chandrasekar ***@***.***>; Mention ***@***.***> Subject: Re: [gdsfactory/kgeneric] kfactory snapping issues (Issue #17) yes, see the code here import kfactory as kf from kgeneric import gpdk as pdk if __name__ == "__main__": c = kf.KCell("bend_chain") b1 = c << pdk.bend_euler_sc(angle=37) b2 = c << pdk.bend_euler_sc(angle=37) b2.connect("o1", b1.ports["o2"]) # b1.flatten() # b2.flatten() c.flatten() c.show() — Reply to this email directly, view it on GitHub<#17 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AX72Z2556QRUYLC7YJ7XRWTXVRN2BANCNFSM6AAAAAA3R6ZOVY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sebastian-goeldi]

Yes, if you use non-manhattan devices, well, you can connect them, but you'll have to do flattening & fixing & smoothing anyway. Because there are two problems: a) I cannot guarantee you that the origin of your second cell will land on a grid point (which it must) and b) I cannot guarantee that your port of the 37° side is truly on the intersection of the two points from the sides of the waveguide (it most certainly isn't).

There are tricks I could play to solve this with a dofferent transformation, but it could have (severe) drawbacks:

1. Use the polygons before you even insert them into the euler bend cell (this almost certainly would work)
2. Do 1) but pick the polygons from the cell. <- no snapping but almost certainly a small angle mismatch, meaning you could get a ever so slight fold in the connection
3. I could make a transformation using the two points of the waveguide instead of the center point. <- quite computationally heavy and you will not fix all issues

[sebastian-goeldi]

The solution I would propose is exactly what Skandan said. If you want non-manhattan devices, use a path instead of devices, it will be the path of least resistance ;).

Or with the new pdk implementation, you could make a euler bend on e.g a 0.1nm grid, connect and flatten there, snap to a 1nm grid and hope you fixed it ;).

[SkandanC]

Sounds great! I'm curious how 1. would work, how would using polygons before they're in the cells work?

…

________________________________ From: sebastian-goeldi ***@***.***> Sent: Wednesday, August 16, 2023 2:14 AM To: gdsfactory/kgeneric ***@***.***> Cc: Skandan Chandrasekar ***@***.***>; Mention ***@***.***> Subject: Re: [gdsfactory/kgeneric] kfactory snapping issues (Issue #17) The solution I would propose is exactly what Skandan said. If you want non-manhattan devices, use a path instead of devices, it will be the path of least resistance ;). — Reply to this email directly, view it on GitHub<#17 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AX72Z23NPKZCCRDVEEQNPNLXVRQN3ANCNFSM6AAAAAA3R6ZOVY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sebastian-goeldi]

Sounds great!

I'm curious how 1. would work, how would using polygons before they're in the cells work?

If you have the extruded Eulerpath, it's a DPolygon. You can easily transform them around without issues, without having to bother about the grid anywhere (as long as you have accurate points for transformations). So in there as long as your float (or probably rather double) machine accuracy is high enough, you will not have snapping issues. Only when you then insert them, they get snapped, but since the points should be super close, they will probably snap to the same point in almost all cases.

But, for eulerbends this would be quite backwards, because at that point you have information about the backbone, which allows you to just use that for extruding a new bend with no snapping involved anywhere.

[tvt173]

it often gets talked about as a weakness that gdstk uses floating point numbers for polygon points, but here I think it is a strength... floating point precision will be kept until GDS export, which allows something like the flatten_invalid_refs GDSWriteSetting in gdsfactory to fix this class of snapping error. if you snap at the point of inserting polygons into the Cell, like is done here, it becomes much more difficult and awkward to acheive this same effect

https://gdsfactory.github.io/gdsfactory/notebooks/04_routing_non_manhattan.html