Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kfactory snapping issues #17

Open
joamatab opened this issue Aug 16, 2023 · 9 comments
Open

kfactory snapping issues #17

joamatab opened this issue Aug 16, 2023 · 9 comments

Comments

@joamatab
Copy link
Contributor 

import kfactory as kf
from kgeneric import gpdk as pdk

if __name__ == "__main__":

    nm = 1e-3
    c = kf.KCell("bend_chain")
    s1 = c << pdk.straight_sc(length=1+1.5*nm)
    s2 = c << pdk.straight_sc(length=1)
    s2.connect("o1", s1.ports["o2"])
    # b1.flatten()
    # b2.flatten()
    # c.flatten()
    c.show()

This creates 1nm issues

image

@sebastian-goeldi
@tvt173
@SkandanC
@tvt173
Copy link

tvt173 commented Aug 16, 2023

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

@sebastian-goeldi
Copy link

sebastian-goeldi commented Aug 16, 2023 •
edited
Loading

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
Copy link
Contributor Author

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
Copy link
Collaborator

SkandanC commented Aug 16, 2023 via email

@sebastian-goeldi
Copy link

sebastian-goeldi commented Aug 16, 2023 •
edited
Loading

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
Copy link

sebastian-goeldi commented Aug 16, 2023 •
edited
Loading

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
Copy link
Collaborator

SkandanC commented Aug 16, 2023 via email

@sebastian-goeldi
Copy link

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
Copy link

tvt173 commented Aug 16, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tvt173 @joamatab @sebastian-goeldi @SkandanC