Unintended grid snapping and scaling of objects when transformed using Python API

anlinus

Hi there,

When generating geometries using the python API I noticed that when I transform my objects (could be polygons, boxes or paths), i.e., distributing a shape along a certain path, I can see that the tranformed shape snaps to the grid and slightly changes its dimensions. For example, if I have a box which I transform to a certain coordinate, it will snap to the grid and slightly change it's dimensions.

For my application, this is not really desirable, since the features are relativly small and sometimes, objects that should mathematically join together are separated with a small gap. Is this an intended feature or can you get around it somehow? Does it matter if I use micrometer or integer units? FYI I use micrometer units as of now.

The structures I have is relativly small (a couple of hundred nm in width). I would think that it does not matter to much for my circuits if I compensate for this snapping, so I might be able to live with this feature. But if I don't it would be very nice!

Best regards,
anlinus

RawrRanger

Hi anlinus

Further reduce the file grid size should be the way to reduce the occurance iof this issue, however is you are already using the highest resolution possible, than y moving the objects in a interger grid unit should helps.

Another way is to make the shapes that suppose to be together into a cell, this should allows you to move shapes freely without having to deal with the pattern gap caused by off grid during the process.

Matthias

Yes, thanks once again for the explanation

@anlinus A Layout will always have some fundamental grid as coordinates are integer multiples of the database unit. So when you plan some layout, make sure that all resulting shapes are on that grid.

Internally, before you put polygons into the database, you can use the "DPolygon" objects which are floating-point objects without this limitation. You can freely transform them and the accuracy is limited only by the nature of the 64bit double precision format. But once you store them into the database using "Shapes#insert", they become translated into integer-types and are snapped to the database unit.

So bottom line is: use "DPolygon" (DBox, DPath ..) as long as you're outside the database. Once you are ready for storing them, make sure they are on the database unit grid - in your case, the displacement is multiple of the grid and also the scaled polygons are. If required reduce the database unit, but be aware that smaller database unit means smaller usable range in total, as the integers in GDS are 32 bit wide.

Matthias

anlinus

Thanks for your answers, I understand why this is happening better now. Decreasing the grid size does a good enough job, the components still snaps/scales a little bit but in less destructive way that will work for my application. All the best // anlinus