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

[quaeritis]

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

[klayoutmatthias]

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]

I’m working on a practical KLayoutPCell class that is suitable for both the python module and the PCellDeclarationHelper. I second what Matthias said: it is only useful to go through that if you need to use it on the GUI. Let me know if you are interested and I’ll notify here once I put together some code and documentation. On May 10, 2019, at 12:29, Matthias Köfferlein <notifications@github.com<mailto:notifications@github.com>> wrote: 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 which you can later modify in the editor. Matthias — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#264 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAIJZE24WQRVDTSURFIOQRTPUXEIVANCNFSM4HLHKXOQ>.

[lukasc-ubc]

Hi Thomas, I am interested in what you propose.

…

On May 10, 2019, at 1:38 PM, Thomas Ferreira de Lima ***@***.***> wrote: I’m working on a practical KLayoutPCell class that is suitable for both the python module and the PCellDeclarationHelper. I second what Matthias said: it is only useful to go through that if you need to use it on the GUI. Let me know if you are interested and I’ll notify here once I put together some code and documentation. On May 10, 2019, at 12:29, Matthias Köfferlein ***@***.******@***.***>> wrote: 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 which you can later modify in the editor. Matthias — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#264 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAIJZE24WQRVDTSURFIOQRTPUXEIVANCNFSM4HLHKXOQ>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#264 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADY37ABL6RTHNZZ5LEYSRATPUXMNRANCNFSM4HLHKXOQ>.

[quaeritis]

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]

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]

Can you explain what you’d like to do with an extension of the Cell class? On 11 May 2019, at 10:11, quaeritis <notifications@github.com<mailto:notifications@github.com>> wrote: 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<https://www.klayout.de/forum/discussion/1130/subclassing-the-cell-class> in the forum. Could pybind11<https://github.com/pybind/pybind11> present a way to simplify the python integration? Best regards quaeritis — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#264 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAIJZE4A3UM4XH7X7W2UABTPU342TANCNFSM4HLHKXOQ>.

[quaeritis]

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]

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]

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]

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