layout.read twice segfaults for a normal GDS #121
Comments
|
Luckily I realized my mistake: https://www.klayout.de/forum/comments.php?DiscussionID=146 But it should still not segfault in my opinion. |
|
You're right, segfaults shouldn't happen. I just wonder what's the mistake in particular ... the discussion mentioned is a bit lengthy :-) |
|
Hi Matthias. It was about not passing the layer map as a read option. That fixed this particular read. |
|
I see .. actually the layer map should not be required. Reading should be perfectly fine. But maybe there is an issue when the file is identical. I need to look into the PCell replacement issue, but I'm afraid that the "read twice" approach is not safe against PCell merging. That's somewhat intrinsic - the "read twice" merge approach is based on a low-level feature that allows "reopening" of cells: when a cell is encountered a second time, the content of the new cell will be read into the first one. That's unsafe in general: if you accidentally used the same cell name in two layouts, reading the second into the first will combine those cells into one, whether that makes sense or not. In case of PCells the actual cell names are not carrying the PCell parameters to be compatible with GDS. So the cell may be called "Basic.TEXT" in both cases, regardless of the actual parameters and KLayout will decide for one parameter set. That's why the cells get messed up. A safe approach is to load the the layouts into two Layout objects and use "copy_hier" to copy over one layout into the other. But I'm afraid this feature does not preserve the PCells as such - they are turned into normal cells. |
|
Sorry just to clarify, do you mean 'copy_tree'? That works, I believe. Except that for my application case I wanted to save individual cells with shared instances into individual .gds files and upon loading them together, the instances would point to the same cell. |
|
Hi Thomas,
I found the root cause of the segfault and I think I can provide a
solution for the "read atop" approach
also with PCells. At least for GDS2.
But if you want to merge the "same cell" into one, the "read atop"
approach is questionable as it would
load the same cell twice (or many more times). So essentially the
content would be duplicated. For a quick
solution this is feasible, but I think in general, a smarter approach
is required: load all layouts individually,
identify the cells that are shared (i.e. by name or if a PCell by
their parameters), prepare the shared
cells in a destination directory and then copy over the top cells
while mapping the child cells to the
shared ones. Sounds a bit complicated, but I guess this is the safe
way of doing it.
Best regards,
Matthias
Zitat von Thomas Ferreira de Lima <notifications@github.com>:
… Sorry just to clarify, do you mean 'copy_tree'? That works, I
believe. Except that for my application case I wanted to save
individual cells with shared instances into individual .gds files
and upon loading them together, the instances would point to the
same cell.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#121 (comment)
|
|
Thank you for looking into this. =) |
0.25.4 (2018-08-25): * Bugfix: KLayout/klayout#121 Issue with multiple reads of GDS2 layouts including PCells * Bugfix: KLayout/klayout#134 Error in cell.fill_region caused by big polygon with spikes * Bugfix: KLayout/klayout#139 Libraries have not been reassigned when loading a GDS file from command line (does not happen on File/Open) * Bugfix: KLayout/klayout#141 Issue with RBA::QHostAddress (ambiguous overload) on Qt5 * Bugfix: KLayout/klayout#142 Issue with RBA::RecursiveShapeIterator#region= * Bugfix: KLayout/klayout#144 The Salt package descriptions are not shown with Motif style * Bugfix: KLayout/klayout#148 Wrong font is used * Bugfix: KLayout/klayout#152 Shapes#size reported a wrong shape count in viewer mode * Bugfix: KLayout/klayout#153 Application crash when editing guiding shape properties * Bugfix: KLayout/klayout#155 Program freezes after replacing nothing by something in Macro editor * Bugfix: KLayout/klayout#157 "Replace cell with ..." rejected cell names with a library prefix * Bugfix: KLayout/klayout#158 Repaint issue on cell context * Bugfix: KLayout/klayout#159 Tech specific macros and DRC scripts were not shown in tech manager * Bugfix: 8 bit indexed GIF images can be used for package icons now * Enhancement: Provide a way to specify the type of a macro This feature is mainly useful for command line arguments. If you run KLayout with "klayout -b -r myscript" it will not be able to determine the type of macro without a suffix. You can now explicitly specify a certain type by giving the suffix implicitly like: "klayout -b -r myscript[rb]" This will read "myscript" but pretend it was "myscript.rb" and execute it as Ruby script. This feature is handy if you need to run a file with a specific interpreter but cannot modify the file name. * Enhancement: Selection now shows PCell display names Before, the internal name was shown for instances * Enhancement: There is an option in the View menu to show or hide markers Markers may hide layout under them. With this feature you can quickly disable all markers and the layout becomes visible.
When I do layout.read twice from python in a particular gds file, the second time it segfaults for some reason.
I am attaching the gds file here. It contains polygons and a Basic.TEXT pcell.
inductor_1030pH.gds.zip
The text was updated successfully, but these errors were encountered: