Error opening an OASIS file created in KLayout

Error: A cell with id 63 is defined already (position=30532, cell=)

I was working with GDS, then switched to OASIS to reduce file size, double checked that I am able to close KLayout and load the design from OAS, continued to work for another day, saved twice - with and without PCell context. Now when I try to open on multiple machines (KLayout version 0.27.11/5/3) I get the error above. Layout Editor manages to open, but the design is messed up. The file it saves cannot be opened in KLayout with a different error. Glade crashes when opening the original OAS

Maybe if I would know what is cell id 63 I would be able to prepare a small example


  • edited November 2022

    You can use to get an ascii view of gds and oasis files.
    Duplicate cells are an error for both gds and oasis, so a small test case will be highly appreciated to fix any potential issue in the klayout oasis writer.

  • edited December 2022

    Can you possibly share the executable for that?
    I tried:
    1) Installed MSYS2
    2) Installed the packages in

    pacman -S make zip mingw-w64-x86_64-gcc mingw-w64-x86_64-make mingw-w64-x86_64-python3 mingw-w64-x86_64-qt5 mingw-w64-x86_64-ruby 

    3) run make and get the following output

    gcc -o dump_oas.o -c  -O3
    In file included from tlStream.h:29,
                     from dbOASISDumper.h:28,
    tlString.h:695:64: error: ISO C++17 does not allow dynamic exception specifications
      695 | KLAYOUT_DLL void from_string (const std::string &s, double &v) throw (tl::Exception);
          |                                                                ^~~~~
    tlString.h:696:61: error: ISO C++17 does not allow dynamic exception specifications
      696 | KLAYOUT_DLL void from_string (const std::string &s, int &v) throw (tl::Exception);
          |                                                             ^~~~~
    tlString.h:697:62: error: ISO C++17 does not allow dynamic exception specifications
      697 | KLAYOUT_DLL void from_string (const std::string &s, long &v) throw (tl::Exception);
          |                                                              ^~~~~
    tlString.h:698:67: error: ISO C++17 does not allow dynamic exception specifications
      698 | KLAYOUT_DLL void from_string (const std::string &s, long long &v) throw (tl::Exception);
          |                                                                   ^~~~~
    tlString.h:699:70: error: ISO C++17 does not allow dynamic exception specifications
      699 | KLAYOUT_DLL void from_string (const std::string &s, unsigned int &v) throw (tl::Exception);
          |                                                                      ^~~~~
    tlString.h:700:71: error: ISO C++17 does not allow dynamic exception specifications
      700 | KLAYOUT_DLL void from_string (const std::string &s, unsigned long &v) throw (tl::Exception);
          |                                                                       ^~~~~
    tlString.h:701:76: error: ISO C++17 does not allow dynamic exception specifications
      701 | KLAYOUT_DLL void from_string (const std::string &s, unsigned long long &v) throw (tl::Except
          |                                                                            ^~~~~
    tlString.h:702:62: error: ISO C++17 does not allow dynamic exception specifications
      702 | KLAYOUT_DLL void from_string (const std::string &s, bool &b) throw (tl::Exception);
          |                                                              ^~~~~
    make: *** [Makefile:20: dump_oas.o] Error 1
  • edited November 2022

    Sorry, I'm not familiar with msys.
    But googling your errors, it seems this was still allowed with c++11, so -std=c++11 might help.
    PS: If you use ``` in a line before and after code or log output, it's going to be easier to read.
    You can edit old posts.

  • Makefile:14 CCFLAGS=-O3 -std=c++11

  • edited December 2022

    Installed Ubuntu in a VirtualBox, ran into similar compilation problems, the suggestion to modify the makefile worked! Dumped my OASIS file (attached), nothing informative there - the problematic cell 63 is one of many similar others. Can I know the hierarchy, where did that cell come from?

    Maybe the true answer that I need is - what is the bullet proof native KLayout format that I can save to and know that I will always will be able to open back?

  • edited December 2022

    Sorry for the inconvenience - basically providing a pre-built dump_oas2 binary should not be an issue, but I'm kind of tired of CI configuration tasks. I'm not a DevOps engineer.

    I debugged your issue and actually it is a side effect of a duplicate cell name: the "WaveguideCoplanarStraight$66" cell is present twice: with ID #63 and #258. And there is another cell name "Waveguide*Coplanar$11" which is also there twice.

    I admit that should not produce invalid OASIS files. Maybe I can patch the reader to read such files even in presence of duplicate names.

    Actually, the current (master branch) writer refuses to write OASIS files with the duplicate cell names to OASIS or GDS2.

    I have patched your layout by renaming these two cells and attached the repaired OAS file.

    The big question is how it is possible to generate such duplicate cell names. These name$... cells are variants generated during PCell instantiation. Usually KLayout takes care of making their names unique. The only way known to me to create duplicate cell names is through scripting. Any idea what could have gone wrong?



  • I have created a ticket for a repair feature for future releases:

  • Dear Matthias,

    1) Thank you for all this great project that you do
    2) With Stefan's help I managed to build the dumper code, so I guess it is fine.
    3) Thank you for debugging my issue and saving my work
    4) I did not find cell name $66, but I did find $11, and it was a completely normal PCell instance, instantiated through the GUI, similar to dozens of others of the same type
    5) I double checked the fix by opening the restored file and saving it again, and indeed, v0.27.11 creates a corrupted copy while 0.27.13 makes a readable one.
    6) I think the best way for me is that the writer will refuse to write a corrupt design rather than the reader to try and overcome it
    7) I will keep an eye on this bug (by noting at what stage does the writer refuses to write).

    Thank you again,

  • edited December 2022

    @srjmas Thank you for your feedback.

    I cannot entirely rule out a bug in KLayout which generates duplicate cell names. Guaranteeing unique names unfortunately isn't easy unless you impose severe restrictions on the API.

    I am about to release the next major release which has a few bug fixed in that area and the writer failsafe in place and I will consider providing some kind of fallback (after convincing @StefanThiede :) ).

    Please keep looking - I'm open to fixing weird issues in the PCell domain, specifically when there are freaky side effects like this.

    Best regards,


  • I think the problem is related to copy paste. I continued to work on my design (attached) and now I have a weird PCell that combines the paths of two different ones - you can see it in cell "chip1qb" as "Waveguide*Coplanar$11" and in cell "QTPL" under the same name. I was working on the QTPL - creating PCells from scratch and copy-pasting them - saving the file under new names and opening periodically, until after opening I noticed the problem (it was not present before I closed the file). Also in the previous time, the problematic PCell was one that I copy-pasted manually. I tried to reproduce it in a small example, but without success

  • Thanks for this hint. I'll try to reproduce the issue myself.


Sign In or Register to comment.