Paths

I want to apply a taper or attach bridges along an entire path. Can I do this without having to worry about each individual segment in the path?

You can use the simplify! function to combine some range of segments into a single compound segment with a single style.

A caveat: Decorated styles should not become part of compound styles, for now. Avoid this by decorating / attaching references at the end.

I want to apply MeshSized or OptionalStyle to a path. How do I do that?

Short answer: my_style(simplify(my_path)).

Longer answer: A GeometryEntityStyle can only be applied to a GeometryEntity, but a Path is a GeometryStructure. However, simplify(my_path) returns a single GeometryEntity describing the entire path. (simplify is not to be confused with simplify!, which modifies the path to contain only that entity, as in the previous question.) That entity can then be styled and placed in a coordinate system as usual: place!(cs, my_style(simplify(my_path)), metadata).

Caveat: Any attachments to the path are discarded when that entity is used outside a path. (See the following question.)

Note that this will still not work for Rounded, which can be applied only to AbstractPolygon. To round the ends of a path, you can use terminate!.

Why is Path a GeometryStructure rather than a GeometryEntity?

Path is a GeometryStructure because it can contain references to other structures (added using attach! or overlay!).

Meanwhile, a GeometryEntity can only be associated with a single piece of metadata. The metadata applied to a Path is not shared by those references, so Path can't be a GeometryEntity.

Note that it is possible for a GeometryEntity to define disjoint shapes. They just have to share metadata when placed in a coordinate system. For example, a straight CPW segment can be represented as a single entity, even though it defines two disjoint rectangles, since they must have the same metadata. Specifically, a CPW-styled segment is represented as a Paths.Node <: GeometryEntity, which combines a Paths.Straight segment and a Paths.CPW style. (Path styles are unrelated to GeometryEntityStyle.)

A Path then contains a vector of Paths.Node. While these nodes do all share metadata, they can also have styles that attach references along the segment. If a node is used as its own entity outside the context of a Path, however, those references are ignored.

GDS output

I can't save my GDS file.

Try deleting any file that happens to be at the target path. A corrupted file at the target path may prevent saving.

When I refresh KLayout after saving changes to a file, everything disappears. Where did it go?

The most likely answer is that the name of the top-level cell changed. To show the new geometry, right click on the cell name in the upper left panel and choose "Show As New Top". To avoid this in the future, make sure your top-level cell has a fixed name, rather than something generated by uniquename. For example, if you are saving the result of a flatten operation, you can use the name keyword argument in flatten.

When I look at my final GDS file, there are ~1nm gaps between edges that should coincide. Why is this happening, and can it be avoided?

This can happen for at least two reasons, both of which are related to the use of integer coordinates in a database unit (typically 1nm) by the GDSII format.

1. Gaps between elements in the same Cell can occur if you have two line segments that are meant to be collinear but have different endpoints. The four endpoints will be rounded to four points on the integer grid, and these four points will not necessarily be collinear. One solution here is to insert a point in either line segment where any endpoint of the other falls. This is how an open CPW termination created by Paths.terminate! is drawn (when not using rounding), instead of just placing a four-point rectangle at the end of the CPW.

2. Gaps between elements in different Cells can occur if you're using CellReferences (corresponding to SREF in the GDSII format described here), since coordinates within each cell as well as the origins of cell references are rounded to integers on saving. This occurs particularly often when rotating references by angles other than multiples of 90 degrees. One solution is to flatten cells before saving, since DeviceLayout's internal representation of Cells uses 64-bit floating point precision.