It looks like you're new here. If you want to get involved, click one of these buttons!
We just overcome an issue about a user error causing an issue to open the exported gds in another GDS tool.
Issue was that the user has a cell inside the hierarchy named basic.donut(r=97..101). Some viewer used at the FAB can't handle it properly. Some tools simply rename such inconsistant cell names.
Question: Is there a consistancy check in place to be used? In case not I'm thinking about implementing one checking the cell hierarchy, should be doable.
Second part is an issue in the Linux release: When I run open and double click on a file it opens twice (different panel). I have to select the file and click open to avoid. I also tried to slow doen mouse speed on selection but this dosn't help. In windows it works fine. Probably my environment ...
Can you try "Save As" and unbox the "Cell context" option (Store PCell and library context information (format specific)???
Do not overwrite the original gds file as all pcell information will be lost (to be avoided in case you need to adapt the design later on)...
Thomas suggestion is pointing the right way: if you strive for compatibility, remove the PCell information. KLayout annotates GDS in a special way so it can read back the PCell parameters.
However, I wonder about the cell name: the GDS cell names KLayout produces are compatible ones. "basic.donut(r=97..101)" is a "decorated cell name" which KLayout does not produce inside GDS. Instead the GDS cell name will be "DONUT$x" where x is a disambiguation number. "basic.donut.." is the name shown by KLayout to indicate the cell's parameters.
PCell-enabled GDS files are only special in the sense that they introduce a parallel top cell called "$$$CONTEXT_INFO$$$". This cell stores some information for backannotating normals cells to PCells. This scheme is basically compatible with GDS, except there are two top-level cells.
Just to confirm, Tomas's solution is good!