-
Notifications
You must be signed in to change notification settings - Fork 40
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.
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
Add SetOperation to construct more complex geometry #1052
Conversation
c918c02
to
50816d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, I can't follow many of the internals so maybe @weiliangjin2021 can comment on that. But in general I think it will be really nice to have this stuff generalized like this. Thanks @lucas-flexcompute
535a799
to
41a7793
Compare
With both |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My experience of playing with those set operations is great. Lots of fun!
Great! I'll wait for any revisions required from the back-end before merging. |
Also, allow GeometryGroup to accept GeometryGroup instances as group elements. That's because ClipOperation must accept them as operands, so it makes sense to extend the support to GeometryGroup, since the backend code is already in place. Importing a general gds file requires the implementation of `ComplexPolySlab`, but the plugin implementation depends on `Medium` and `Structure` for the `to_structure` method, so it cannot be simply refactored into the geometry namespace. The solution was to have a base class without the problematic method in geometry, which can be used to import gds files. Signed-off-by: Lucas Heitzmann Gabrielli <lucas@flexcompute.com>
797309f
to
e4a1c44
Compare
Also, allow GeometryGroup to accept GeometryGroup instances as group elements. That's because
SetOperation
must accept them as operands, so it makes sense to extend the support toGeometryGroup
, since the backend code is already in place.There's some overlap between
GeometryGroup
andSetOperation(operation="union")
but they are left as is for a few reasons:GeometryGroup
would break backwards compatibilityGeometryGroup
for organization of structuresSetOperation
with more than 2 operands would be strange for difference and symmetric difference operationsOne option would be to have the number of operands depend on the operation, but I'm not sure that's a better options then what is currently implemented because we can't remove
GeometryGroup
anyway.