@kwdef struct GDSWriterOptions

Options controlling warnings and validation during GDS file writing.

Fields

• max_layer::Int = 32767: Maximum layer number that will not throw a warning.
• max_datatype::Int = 32767: Maximum datatype number that will not throw a warning.
• warn_invalid_names::Bool = true: Whether to warn about cell/text names that violate the GDSII spec (must be ≤32 chars, only A-Z, a-z, 0-9, '_', '?', '$').

Warnings for layer number and datatype are configurable because different tools may have different limits. In the GDSII specification, layer and datatype must be in the range 0 to 63, but modern tools are rarely so strict. The hard limit is that the layer and datatype records are each two bytes. In the specification, they are two-byte signed integers, and for tools that conform in that regard, the maximum value is 32767. For that reason, larger values will cause a warning to be shown by default. However, a common extension of the format interprets these records as unsigned integers, allowing values up to 65535.

Examples

# Default: modern limits, name warnings enabled
opts = GDSWriterOptions()

# Strict GDSII spec compliance
opts = GDSWriterOptions(max_layer=63, max_datatype=63)

# No warnings at all
opts = GDSWriterOptions(
    max_layer=typemax(UInt16),
    max_datatype=typemax(UInt16),
    warn_invalid_names=false
)

save(file::File{format"DXF"}, c::Cell, python::String)

Export a Cell to a DXF file. Uses the ezdxf program in Python, and requires the python executable path that has that package installed (could simply be python, or /Users/user/.julia/conda/3/bin/python). Generates a Python script and runs it, to avoid PyCall dependency.

save(::Union{AbstractString,IO}, cell0::Cell{T}, cell::Cell...)
save(f::File{format"GDS"}, cell0::Cell, cell::Cell...;
    name="GDSIILIB", userunit=1μm, modify=now(), acc=now(),
    options=GDSWriterOptions(), spec_warnings=nothing, verbose=false)

This bottom method is implicitly called when you use the convenient syntax of the top method: save("/path/to/my.gds", cells_i_want_to_save...)

Keyword arguments include:

• name: used for the internal library name of the GDSII file and probably inconsequential for modern workflows.
• userunit: sets what 1.0 corresponds to when viewing this file in graphical GDS editors with inferior unit support.
• modify: date of last modification.
• acc: date of last accession. It would be unusual to have this differ from now().
• options: a GDSWriterOptions controlling validation of Cell names and warnings for maximum layer/datatype numbers.
• spec_warnings: if false, disables all warnings for max layer/datatype and invalid names
• verbose: monitor the output of traverse! and order! to see if something funny is happening while saving.

save(file::File, sm::SolidModel)
save(filename::String, sm::SolidModel)

Save a SolidModel instance to a file or filename.

Using FileIO.save, supported filetypes using for OpenCASCADE geometries are .brep and .stp. Meshes can be exported as .msh2 (compatible with Palace) or .msh (most recent Gmsh format) files.

Using DeviceLayout.save, you can also choose any other extension supported by gmsh.write() like .xao.

load(f::File{format"GDS"}; verbose::Bool=false, nounits::Bool=false)

A dictionary of top-level cells (Cell objects) found in the GDSII file is returned. The dictionary keys are the cell names. The other cells in the GDSII file are retained by CellReference or CellArray objects held by the top-level cells. Currently, cell references and arrays are not implemented.

The FileIO package recognizes files based on "magic bytes" at the start of the file. To permit any version of GDSII file to be read, we consider the magic bytes to be the GDS HEADER tag (0x0002), preceded by the number of bytes in total (0x0006) for the entire HEADER record. The last well-documented version of GDSII is v6.0.0, encoded as 0x0258 == 600. LayoutEditor appears to save a version 7 as 0x0007, which as far as I can tell is unofficial, and probably just permits more layers than 64, or extra characters in cell names, etc.

If the database scale is 1μm, 1nm, or 1pm, then the corresponding unit is used for the resulting imported cells. Otherwise, an "anonymous unit" is used that will display as u"2.4μm" if the database scale is 2.4μm, say.

Warnings are thrown if the GDSII file does not begin with a BGNLIB record following the HEADER record, but loading will proceed.

Property values and attributes (PROPVALUE and PROPATTR records) will be ignored.

Encountering an ENDLIB record will discard the remainder of the GDSII file without warning. If no ENDLIB record is present, a warning will be thrown.

The content of some records are currently discarded (mainly the more obscure GDSII record types, but also BGNLIB and LIBNAME).

If nounits is true, Cell{Float64} objects will be returned, where 1.0 corresponds to one micron.