Reply To: Accuracy of path lengths & length_geo attribute

[Ronald]

Dear Jon,

Thanks for the question. I think there are a number of dimensions to this problem: gds hierarchy, arc length and shape area. Thanks for mentioning the area script.

Starting with the hierarchy. If you build a structure using multiple cells, each cell will snap floating point positions to the local integer cell grid. If you connect those cells again floating point accurate to other cells or each other, their grids likely have an offset (translation and/or rotation) with respect to each other, such that the grid nodes do no exactly overlap. This leads to overlaps or gaps of shapes of max sqrt(2)*gridsize. The most straight forward way to resolve this is the use a single grid to snap all structures on, i.e. by flattening them in to a single cell. For a series of Nazca interconnects this is easy to do. An alternative way is to wait until mask export and reposition an instance such its grid matches the parent cell, while relocating everything in the cell in the opposite direction. This may require to generate multiple copies of the cell.

As for the length of a waveguide, the center line of a waveguide, which can be curved, is discretized in a linear piecewise fashion to create a shape, which in the limit of an increasing number of elements will give the, say, mathematical length. Each floating point linear segment is slightly shorter than the arc points it connects, so the sum of the elements on a circular arc is a bit shorter than the mathematical length it represents. (Although the lines can also cut the arcs such that the arc is equally right and left of the line segments.) In gds export those points have to snap to the gds integer grid. This step actually may lead to a slightly larger, but more likely, again a slightly shorter, center line. It depends on how the smooth curve shape is positioned on the grid. The geometrical length stored in the element in Nazca is its mathematical length, not the sum of the linear elements. Note the linear elements could be considered before or after grid snapping.

Finally, the area. A waveguide will have two egde polygons, for which the same arguments apply as for the center line. From the waveguide area, the arc length can be extracted, as you indicate. For a grid of 1 nm the area can be filled in steps of 1 nm^2. The gds tile shape still has to follow the waveguide, so in practise the area steps with be several times that resolution when changing the width or radius of the waveguide. To match the area in the gds such that it yields the correct center line length may need a tiny adaptation of the radius and or width. The adaptation depends on the deviation of the extracted arc length from the mathematical length. Note this has to be on the final gds grid, i.e. the toplevel grid after flattening, or on a cell whose grid overlaps the topcell grid, to not change the result after flattening.

That said, your increased resolution to 1e-12 will effectively lead to higher sampling on a finer grid, and all curves will be smoother and closer to their mathematical length. So yes, it works. However, if you send your mask off to the mask vendor they will regrid your mask to their process resolution, which brings you back to square one, e.g. the 1 nm resolution. Hence, ideally you know exactly what happens to your gds before it enters the litho.

Also, be aware that the effective refractive index in curves is different from that in straight waveguides. This may lead to significant phase errors when not taken into account.

Regards,
Ronald