ok, on my own machine now

Got it, thanks. Sorry for the delay.

Thanks Tim, Im using git version of magic

I made several fixes to the LEF commands on that day and again in the following days. It's not clear from my notes that any of those changes would fix a potential crash condition, but it's worth pulling a more recent version and trying.

Ok, Ill try that. Here is the .mag of the missing file in case it was that which is breaking it. Ill pull the most recent version and try again, thanks, John

I was able to do the same

lef write -hide

with the previously missing cell added, so I expect there is something I did in one of those recent commits that fixed whatever is ailing it.

The latest git version of magic doesnt crash with >>>lef write -hide, so thats now working OK. Next thing I found was messages when writing gds Generating output for cell sky130_fd_sc_hd__buf_4 Calma output error: Structure name not found at GDS file position 344098 Calma output error: Can't write cell from vendor GDS. Using magic's internal definition

@john wood: Since the years I worked at MultiGiG, I've been trying all sorts of things to resolve the problems that magic has with reading in GDS made with other layout tools, many of which allow people to create absurd hierarchies; Calibre can slice and dice things every which way to extract a valid netlist from the worst layouts. I think this has just encouraged people to be very bad at doing layouts. Anyway, the upshot is that this situation just gets worse and worse over time. My best way to deal with it is to make a reference from a magic layout to a GDS file using a "property" key:value pair in the cell, so that when you want to write GDS, magic will just go find the GDS file and pull the vendor GDS directly instead of trying to create it on its own. That, however, depends on the properties pointing to a valid GDS file. For the PDK generated by open_pdks, I have open_pdks set it all up at the time it builds and installs the PDK, so that the .mag files and the .gds files are all consistent, and each cell in magic has a property pointing to the correct positions in the corresponding GDS file. Obviously, this method is pretty easy to subvert by overwriting the GDS file with another one and not updating the properties in the .mag files. That appears to be what happened to your layout. The fixes for it are either (1) rebuild the whole PDK so that everything is consistent, or (2) remove the GDS file that the .mag files are referencing. I'm not entirely sure what went wrong, though, because in the output you posted, magic has detected that the GDS file doesn't match the pointers and has decided to write its own GDS, which should have been okay. There might be an error in the magic code there; I don't think that part of the code has been well tested. I will look into it.

thanks Tim, Ill rebuild the pdk and see if that does it.

(Sorry about the delay in responding; I was down in Virginia visiting my parents for the last few days.) At least in the recent past, I have been able to work around the obscure Conda errors in the PDK build (which come from the Google repository, not from open_pdks) by doing "make" twice in a row, and the error doesn't repeat the second time.