Closed lukasc-ubc closed 1 month ago
Hi Lucas,
I guess the problem with the defunc cells is clear - if the technology is not there, these cells cannot be connected.
About the two instances and the name: I see that the strange name is already inside the GDS file. It is not something that KLayout invents.
Basically, all library cells have an alias name and in fact you can change it to anything - if you go to the cell in the cell tree and choose "Rename Cell" from the context menu, you can assign any valid name to the cell. This will become the basic name, but as the cell is internally connected to the library, it is still shown as EBeam.ebeam_gc_te1550
. In the end, it is not really important, how the cell is named - it is just easier to see the cell's real origin in the final GDS file, if you don't rename it.
The strange thing is the duplicate cell.
Usually, when you place a cell from a library, KLayout does not create a new alias cell, unless the library cell is a PCell and there is no variant with the same parameters yet.
I tried a few ways to trigger this problem, like renaming and copy/paste from another layout - without success.
Maybe it is possible to trigger this problem in other ways, i.e. when importing from another layout, or when generating layout by code. Another reason may be that this layout was made with an old KLayout version. Maybe you have some further hints for me.
In any case, I don't think that is a serious problem. It looks like KLayout correctly attaches both cells to the library, even if they are identical.
Best regards,
Matthias
Hi Matthias,
I exported the GDS into the text format, and that helped provide more details. The student that generated the design indeed created a GDS in another tool, saved it as PhC14.gds, then edited the layout in KLayout. So somehow the name got attached.
SNAME PhC14
XY 0: 0
PROPATTR 1
PROPVALUE CELL=ebeam_gc_te1550
PROPATTR 0
PROPVALUE LIB=EBeam
ENDEL
SREF
SNAME ebeam_gc_te1550
XY 0: 0
PROPATTR 1
PROPVALUE CELL=ebeam_gc_te1550
PROPATTR 0
PROPVALUE LIB=EBeam
ENDEL
ENDSTR
I wasn't aware that the SNAME (basic_name) property could be different than then PROPVALUE CELL. Indeed, doing the Rename operation shows the SNAME (PhC14).
I added this check in case it happens again:
for c in layout.each_cell():
if c.basic_name() not in c.name:
raise Exception ('- WARNING: cell SNAME (basic_name = %s) does not match the cell name (name = %s). See https://github.com/KLayout/klayout/issues/1714' % (c.name, c.basic_name()) )
On a related note, I was just checking the cell properties to see if I can see these values. I do an Edit > Properties, then User Properties, and I get a KLayout crash. I notice it was already reported and fixed: https://github.com/KLayout/klayout/issues/1706
thank you Lukas
Hi Lukas,
yes, the crash-on-show properties bug is fixed. It only happens on MacOS, that's why I did not catch it. I will release 0.29.2 end of this month.
Best regards,
Matthias
P.S: Okay to close this issue, or should we leave it open until there is a clue how the two cells were created?
Hi @klayoutmatthias
I have a strange bug:
Start with the attached GDS, which was created using the technology "EBeam", and view the cell listing:
Open the same file without the Technology available in KLayout:
Save as (without Context info), then load again, results in:
Notice that the cell is instantiated in two cells, and after saving, one of them is renamed "PhC14". I have no idea where this name is coming from!
I came across this problem when running it in a Python script. I was loading the file, without a technology in place, and noticed that cell.name was PhC14, whereas cell.basic_name() was correctly given as ebeam_gc_te1550.
gives the following:
Any idea how this is happening?
Strangely, out of fifty files, only this one has this problem.
This is with KLayout 0.29.0 and 0.29.1
thank you Lukas
EBeam_openEBL_arunaPBS3_LC.gds.zip