Home Forums Nazca Hashme with multiple cells

Tagged: 

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #5990
    ale35
    Member

    Hello,

    I am trying to generate a layout containing several cells and I wish to avoid to regenerate the same cells over and over. I understand how this can be done with a single cell using the hashme decorator, but I have some doubts on how to set up my script, which contains nested cells and functions defining parametrized cells.

    I do not understand:

    – Where is the best place to place all the @hashme lines ? If I collect them all together at the beginning of the script, I receive a warning.
    – What is the effect of the ‘hashme = True’ parameter ? The cell seems to be hashed anyway.
    – Why do some of the hashed cells contain an additional name identifier ‘_$####’ and others do not?
    – Why some of the cells end up with a text field listing their parameters, and others not?
    – Is there an alternative way to tell Nazca to always check for already generated cells (based e.g. on the cell name), rather than having to manage this decorator for each cell?

     

    Below an example code, where the ‘mmi1x2’  cells gets the additional name identifier, but no parameter string printed, differently from the ‘cm’ cells.

    @nd.bb_util.hashme(‘mmi1x2’)
    def mmi1x2():
    with nd.Cell(‘MMI_1x2’, hashme = True) as mmi1x2:
    ….
    return mmi1x2

    @nd.bb_util.hashme(‘cm’)
    def cm():
    with nd.Cell(name=’cm’, autobbox = True, hashme = True) as cm:
    ….
    return cm
    Thank you.

    #5993
    Ronald
    Keymaster

    Dear ale35,

    The tutorial on hashme may be of help.

    All cells generated by hashed function calls have the _$#### hash suffix as unique identifier.
    In newer Nazca versions (0.5.7 and up) the hashme=True has become optional in de Cell() call.

    The hashme decorator does not only check for the cell name, but for the full call profile and it generates a unique cell name based on that (with the hash). You can also manage cell names yourself and simply send or generate a unique cell name every time you call your cell generating function. Hashme does all the work for you in one line with a few characters in case of parametrized cells.

    Ronald

    #5995
    Xaveer
    Moderator

    Dear ale35,

    Because your cell does not seem to take any parameters, the hashme (and even the function definition) are not needed. Just define the cell (in a with statement) and use it:

    import nazca as nd
    
    with nd.Cell("MMI_1x2") as mmi1x2:
        nd.strt(length=10, width=5).put()
    
    for i in range(100):
        mmi1x2.put(i * 10, i * 10)
    
    nd.export_gds()
    

    Xaveer

    #6094
    winigerj
    Member

    Dear Ronald and Xaveer,

    Just on that topic. I found it to be extremely useful to use **kwargs for the function definitions, as this provides a lot of flexibility (as eg. pass down arguments from func to func).
    But it seems, that when defining the function solely with  kwargs as argument, like: (sorry, somehow i did not manage to make markdown/html block code work here)

    @nd.bb_util.hashme('func')
    
    def func(**kwargs):
        with nd.Cell(hashme=True) as C:
            # stuff with kwargs
        return C

    The hashme seems not to notice any change in the kwargs. So if I change e.g. the kwarg[‘angle’] parameter, the hashme doesn’t get the change of variable and gets the first instantiation with the old angle parameter.

    Is there a way to change this behaviour, or do I need to give all the params explicitly to make it work?

    Thanks already!

    Best,

    Joel

    #6096
    Ronald
    Keymaster

    Dear Joel,

    I checked that indeed **kwargs fed parameters do not pop up in the hashme after introspection (via inspect module). My guess (observation?) is that **kwargs are dealt with in another corner of inspect and are hiding there. Something to investigate…

    Ronald

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