Home Forums Nazca Questions and Answers Calibre DRC crashes: Failure to read input file stdin.gds at record offset 282.

Tagged: ,

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #5554
    Andreas
    Member

    Dear,

    I want have a class-based architecture in my design, so I can inherit from already made components. For some reason this seems to create problems in my DRC tool (Calibre crashes with the message “Failure to read input file stdin.gds at record offset 282.

    An example of the class hierarchy is attached below. When putting the straight waveguide at angle 0 it runs fine, when putting the angle to 180 the crash occurs in the DRC (it’s not a DRC error, but calibre actually crashes).

    Have you seen this before? Could you advise how to solve this?
    Kind regards
    Andreas

    # --- Example ---------------------------------------------- #
    
    import nazca as nd
    import nazca.demofab as demofab
    
    class Default_Class():
        def __init__(self, *args, **kwargs):
            self.insts = None
    
        def put(self, *args, **kwargs):
            if self.insts == None:
                self.insts = self._generate_instances()
            return self.insts.put(*args, **kwargs)
    
        def _generate_instances():
            raise NameError('Please override the _generate_instances method and return a cell')
    
    class WaveguideInClass(Default_Class):
        def __init__(self, L, ic, name='WG', *args, **kwargs):
            self.name = name
            self.L = L
            self.ic = ic
            Default_Class.__init__(self, *args, **kwargs)
    
        def _generate_instances(self):
            with nd.Cell(name=self.name) as wg:
                b1 = self.ic.strt(length=self.L, arrow=False).put()
            return wg
    
    ic = demofab.deep
    # ic.strt(length=20, arrow=False).put(200, 0, 0) # This runs ok
    ic.strt(length=20, arrow=False).put(200, 0, 180) # This crashes
    r2 = WaveguideInClass(L=100, ic=ic).put()
    
    nd.export_gds(filename='GDS_test\\stdin.gds')
    #5556
    Ronald
    Keymaster

    Dear Andreas,

    That’s quite a class structure for drawing a waveguide, but I guess you have bigger plans with that.
    The question is if those extra structures are changing anything in the gds that you are generating, but I don’t see how that would be possible.

    I can view both gds cases you describe without a problem in KLayout, so the gds files seem okay from that perspective.

    I am aware there have been crashes in Calibre several years ago due extensive use of curved waveguide structures as they may occur in photonics, e.g. in AWGs. That was fixed in Calibre. In this case I don’t see immediately how the 180 degree would change anything significant.

    A way forward is to export the gds in ascii format and see if it provides hints:
    nd.export_gds(filename='GDS_test\\stdin.gds', ascii=True)

    A second thing to try is to replace WaveguideInClass(L=100, ic=ic).put() by demofab.deep.strt(lenght=100).put(), which should give you the same gds, and check whether Calibre thinks the same.

    Ronald

    #5562
    Ronald
    Keymaster

    Dear Andreas,

    If the issue is not resolved yet, could you post the resulting .asc file generated by your example above with “ascii=True” in export_gds()?

    Being picky on naming, note that the method named “_generate_instances” in the example returns a Cell object rather than an Instance object.

    Ronald

    #5565
    Andreas
    Member

    Dear Ronald,

    When I exchange the WaveguideInClass by demofab.deep.strt calibre does not crash.

    When I turn on the ascii boolean, the export_gds method crashes, even when there is only demofab.deep.strt objects being used. The error given is:

    nd.export_gds(filename=’GDS_test\\stdin.gds’, ascii=True)
    File “C:\ProgramData\Anaconda3\lib\site-packages\nazca\layout.py”, line 1656, in export_gds
    info=True, flat=flat, clear=clear, bb=bb, **kwargs)
    File “C:\ProgramData\Anaconda3\lib\site-packages\nazca\layout.py”, line 1596, in export
    export.generate_layout(topcells)
    File “C:\ProgramData\Anaconda3\lib\site-packages\nazca\layout.py”, line 1407, in generate_layout
    self.export_topcells(topcells)
    File “C:\ProgramData\Anaconda3\lib\site-packages\nazca\layout.py”, line 1348, in export_topcells
    ga.ASCII_write(GDS.filename+’.asc’)
    File “C:\ProgramData\Anaconda3\lib\site-packages\nazca\gds_import.py”, line 778, in ASCII_write
    f.write(buf.getvalue())
    File “C:\ProgramData\Anaconda3\lib\encodings\cp1252.py”, line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
    UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\u250c’ in position 316: character maps to <undefined>
    Process terminated with an exit code of 1

    #5566
    Ronald
    Keymaster

    Dear Andreas,

    Code ā€˜\u250cā€™ is for some ascii art to visualize structures: ā”Œ
    I guess the encoding error is related to settings in Anaconda on Windows.
    I’ll see if enforcing an encode(“utf-8”) in the ascii export will help out.

    Considering the different behaviour of the two gds exports it may indeed be helpful to checkout the ascii.

    Ronald

    #5567
    Andreas
    Member

    Dear Ronald,

    I forced to write the ascii file in ‘utf-8’ by opening the file as
    with open(filename, ‘w’, encoding=’utf-8′) as f:

    The resulting ascii files are below:

     

    #5568
    Ronald
    Keymaster

    edit: I see you already found this solution before this post.

    Dear Andreas,

    The most straight forward way to try the ‘utf-8’encoding on your system for ascii output is to go to file gds_import.py in your Nazca installation and replace in line 777 with open(filename, 'w') as f: with with open(filename, 'w', encoding='utf-8') as f:. It has also been updated for the next release.

    Ronald

    #5570
    Andreas
    Member

    Dear Ronald,

    I changed line 777 as recommended.

    The resulting ascii files are below:

    I do not see major difference between these files, but perhaps you can see more to it?

    #5575
    Ronald
    Keymaster

    Dear Andreas,

    The class structure does not make a difference and to simplify things, the code below should give the exact same output file as your example in the initial question with 180 degrees:

    import nazca as nd
    import nazca.demofab as demofab
    
    ic = demofab.deep
    
    with nd.Cell(name='WG', instantiate=True) as wg:
        ic.strt(length=100, arrow=False).put()
    
    ic.strt(length=20, arrow=False).put(200, 0, 180)
    wg.put()
    
    nd.export_gds(filename='stdin.gds', ascii=True)

    The problem at the record at offset 282 seems to be the angle record of the sref. If you set instantiate=False in de code above you get the example that you posted as stdin that did not have a Calibre problem. I still do not see why the angle in the sref should be an issue. It is a 8-byte real as it is supposed to be. There is an optional strans record in gds before the angle record. Nazca leaves it out when there is none needed. A wild try is to see if it loads in Calibre in your situation with a strans record added using wg.put(flip=True).

    Alternatively, see what happens when you load the gds in KLayout and save it there to gds again or save the file to OASIS, load it again, and save to gds. After that try to load in Calibre.

    #5577
    Andreas
    Member

    Dear Ronald,

    The code you provided indeed behaves the same as before: it runs when instantiate is false, it does not when instantiate is true.
    When I put wg.put(flip is true), calibre runs, even when instantiate is true.
    When I open a crashing gds in klayout and do a “save as”, Calibre does not seem to crash any longer.

    I’ll run calibre on the re-saved gds files. Hopefully you can track down the problem, so I do not need to insert too many manual steps

    Thank you for looking into this problem! I’ll keep you posted should the problem re-occur.
    Andreas

    #5578
    Ronald
    Keymaster

    Dear Andreas,

    That seems indeed to point to the “optional” strans record.

    A simple fix for your case is to replace in gds.py line 129 (0.5.1) or 127 (0.5) elif adeg != 0 and array is not None: with else:.

    Ronald

    #5579
    Andreas
    Member

    That seems to do the trick for now. Thanks!

    #5582
    Ronald
    Keymaster

    Good to hear, thanks. I will keep this “optional” record added in exports after 0.5.1 as some tools/settings seem to expect it, while in other cases where it is considered optional it should not harm beyond a slightly larger gds file.

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.