Tagged: hashme
- This topic has 4 replies, 4 voices, and was last updated 4 years, 4 months ago by Ronald.
-
AuthorPosts
-
11 February 2020 at 11:22 #5990ale35Member
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.11 February 2020 at 11:35 #5993RonaldKeymasterDear 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
11 February 2020 at 16:58 #5995XaveerModeratorDear 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
16 April 2020 at 13:01 #6094winigerjMemberDear 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
16 April 2020 at 13:34 #6096RonaldKeymasterDear 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
-
AuthorPosts
- You must be logged in to reply to this topic.