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.

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

python exceptions are redirected when PCell is used. (KLayout Python Module) #264

Closed
quaeritis opened this issue May 7, 2019 · 10 comments

Comments

@quaeritis
Copy link

commented May 7, 2019

Currently, python exceptions are redirected when PCell is used.
So there is no exception mend in the terminal when executing the script directly with python.
This makes the error search difficult.

Is there a workaround or better an alternative for klayout.db.PCellDeclarationHelper / klayout.db.Library which is more suitable for pure python scripting.

Is there a need for a more pythonic base class? I think this could still be kept compatible with db.Library

@quaeritis quaeritis changed the title python exceptions werden umgeleitet wenn PCell verwendet wird. (KLayout Python Module) python exceptions are redirected when PCell is used. (KLayout Python Module) May 7, 2019

@klayoutmatthias

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2019

Hello,

Python exceptions are redirected into a text inside the PCell layout to make the error become visible in the layout. But this does not help inside a Python module. I thought it's also printed to log, but I need to check. The PCell code is likely to be executed asynchronously, so exceptions can't be passed.

Anyway, I'm saying this over and over again: PCells are provided as layout editing features, not as algorithmic building blocks for scripts. Instantiating a PCell is just a very complicated way of calling a function that generates layout. If you want to build a design with layout generated by a script, just create the functions or classes which do so. Instead of instantiating a circle PCell, just create the circle. This way you get synchronous calls and exceptions, a truely pythonic design, leaner and more efficient code and so forth. The only acceptable use case for PCells in this context is layout whose PCells you want to modify later in the editor.

Matthias

@thomaslima

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2019

@lukasc-ubc

This comment has been minimized.

Copy link

commented May 10, 2019

@quaeritis

This comment has been minimized.

Copy link
Author

commented May 10, 2019

Hello everyone,

Thanks for the answer Matthias.
Hello Thomas, I would be very interested too.
I also realized in the last days that my use of PCell did not make sense (maybe it was a bit stupid).

I think a kind of PHIDL, gdsCAD or nazca on klayout basis would be great.

There does not seem to be a proper open source 2d CAD library exist, so one limited to 2d, something like Open CASCADE for 2d only, or did I miss something?

Still another question would not theoretically be possible to deliver Package with pip? So the Package could be normal Python packages. I imagined something like this (I know that klayout has salt).

Best regards
quaeritis

@quaeritis

This comment has been minimized.

Copy link
Author

commented May 11, 2019

Hello Matthias,

the problem is that it is apparently not possible to write your own cell classes. That's why you are forced to use PCell if you want to write your own extensions of the cell class. This corresponds exactly to the problem discussed here in the forum.

I would like to do something like this:

import klayout.db as kdb

class TestBox(kdb.Cell):
    def __init__(self):
        super().__init__()
        box = kdb.DBox(0, 0, 100, 200)
        self.l = kdb.LayerInfo(1, 0)
        self.shapes(self.l).insert(box)


lay = kdb.Layout()
testbox = TestBox()
top = lay.create_cell("TestSample")
trans = kdb.DCplxTrans.new(1, 0, False, 0, 0)
top.insert(pya.DCellInstArray(testbox.cell_index(), trans))
lay.write("testbox.oas")

Could pybind11 present a way to simplify the python integration?
pybind11 also integrates Python docstrings which would make it possible to provide Sphinx documentation. Unfortunately, I'm still not quite sure how the GSI works. Is there a more detailed description of this somewhere?

Currently is the documentation of classes and functions in GSI if I saw that right, or?
Would you be interested in a "more extensive / flexible" (is of course a matter of opinion QDoc is also good) documentation?
I am thinking of an infrastructure with Doxygen and asciidoc as used by LibrePCB. I would provide the necessary patches if desired. With pybind11 and Binder it is even possible to get the python documentation from the Doxygen comments.

Best regards
quaeritis

@thomaslima

This comment has been minimized.

Copy link
Collaborator

commented May 12, 2019

@quaeritis

This comment has been minimized.

Copy link
Author

commented May 12, 2019

Hello thomaslima,

I have now edited my post, I think github informed about this not by mail. Like I said, I want to do something like PHIDL on a klayout basis. KLayoutPhotonicPCells seems pretty close to this but is based on PCell.

Best regards
quaeritis

@thomaslima

This comment has been minimized.

Copy link
Collaborator

commented May 12, 2019

You'd need at least the layout in which the cell resides plus its name for a proper constructor. For example, something like this works:

import klayout.db as kdb


class TestBox(kdb.Cell):
    def __new__(cls, lay, name):
        box = kdb.DBox(0, 0, 100, 200)
        layer = kdb.LayerInfo(1, 0)

        _cell = lay.create_cell(name)
        _cell.l = layer
        _cell.shapes(lay.layer(layer)).insert(box)

        return _cell


lay = kdb.Layout()
testbox = TestBox(lay, 'testbox')
top = lay.create_cell("TestSample")
trans = kdb.DCplxTrans.new(1, 0, False, 0, 0)
top.insert(kdb.DCellInstArray(testbox.cell_index(), trans))
lay.write("testbox.oas")

The caveat of the code above is that testbed is a kdb.Cell object, not a TestBox object.

But like Matthias said, I don't think there's much to gain by subclassing cell. I would rather create a high-level code that would use klayout purely to interact with the database objects.

@quaeritis

This comment has been minimized.

Copy link
Author

commented May 13, 2019

Thanks for the example.
I still do not quite understand some things about the API:

  1. Why can not a cell be created independently of a layout?
  2. Why does a cell have to be assigned a layer?
@klayoutmatthias

This comment has been minimized.

Copy link
Collaborator

commented Jul 12, 2019

Sorry for this long delay ... I'm just cleaning up the issue list.

The basic misinterpretation is that the klayout db objects are Python object. They are not! The Python objects are just "windows" into the C++ API. Subclassing of cells is not a concept built into the C++ for good reasons. Only a static data structure provides ways to efficiently implement the lookup trees, a number of caches, efficient shape containers and so forth. Plus Python binding comes with a lot of tradeoffs. PCells aren't dynamic cells either - they are ways to render cells and do not represent cells themselves.

A layout database built on the concept of inheritance is feasible, but that's an entirely different thing. For example, I don't know a way to persist such a thing into a file container in a portable fashion.

The answer the last questions:

  1. A cell is a part of the C++ Layout structure and not an independent object. As said, the Python object is just a "window", or proxy.
  2. PCells can define layer parameters to tell them where to render shapes. You don't need to define a layer parameter if your PCell is going to produce shapes on predefined layers.

I would like to close this discussion as it went off the original topic. This is something for the forum.

Matthias

klayoutmatthias added a commit that referenced this issue Jul 12, 2019
fix for #264
1. Errors in coerce_parameters are now shown as
   red label + warning icon in the parameters dialog
2. Errors during produce are always logged now

Plus: the scroll bars of the PCell parameters page
don't jump back on "Apply".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.