Edit/Modify Menu Commands

The following !set variables affect commands found in the Edit Menu and the Modify Menu.

UndoListLength
Value: integer >= 0.
This variable sets the number of operations remembered in the Undo command. If not set, 25 operations are saved. If set to zero, the length is unlimited.

This tracks the setting of the Maximum undo list length entry area in the Editing Setup panel from the Edit Menu.

MaxGhostDepth
Value: integer 0-8.
This variable sets the maximum expansion depth for instance expansion in ghosting. If not set, this is the same as the normal expansion depth. The actual expansion depth used in ghosting will not be larger than the normal expansion depth, but can be smaller. For example, setting this to 0 (zero) will prevent expansion of ghosted subcells entirely.

This tracks the setting of the Maximum subcell depth in ghosting menu in the Editing Setup panel from the Edit Menu.

MaxGhostObjects
Value: integer 50-50000.
This sets the maximum number of objects to render individually as ``ghosts'' attached to the mouse pointer during operations such as move and copy. This can be set to an unsigned integer in the range 50-50000. If there are more than this number, some outlines won't be shown, the smaller-area objects will be skipped. If subcells are being expanded, objects are rendered top-down, so that if the limit is reached, objects deeper in the hierarchy will not be shown.

The default is 4000 if this variable is not set. If, when moving a large number of objects, the pointer motion is too sluggish, the user can set this variable to compensate, or can limit the subcell expansion depth by setting MaxGhowtDepth if expansion causes the problem.

This tracks the setting of the Maximum number of ghost-drawn objects entry area in the Editing Setup panel from the Edit Menu.

NoWireWidthMag
Value: boolean.
When set, the width of wires does not change when the wire undergoes magnification, in a Move, Copy, or Flatten operation.

The No wire width change in magnification check box in the Editing Setup panel from the Edit Menu tracks the state (set or unset) of this variable.

CrCellOverwrite
Value: boolean.
When set, The Create Cell operation in the Edit Menu and the CreateCell script function can overwrite cells already in memory. This can be dangerous and is prevented by default.

The Allow Create Cell to overwrite existing cell check box in the Editing Setup panel from the Edit Menu tracks the state (set or unset) of this variable.

LayerChangeMode
Value: tri-state.
This variable applies during all move and copy operations, and during the spin command in the physical side menu and similar. In these commands, when objects being moved or copied are ghost drawn as attached to the mouse pointer, it is possible to change the current layer. The operation is then completed by clicking at the new location in a drawing window.

This is a tri-state variable. If not set, there will be no layer change in these commands. Thus by default any current layer change made during the command is ignored by the command. If set to the string ``all'' (case insensitive), then a layer change will apply to all objects being moved or copied. All new objects will be placed on the new layer, regardless of the original layers of the objects. If set to anything else, including to nothing (i.e., as a boolean) then only objects on the previous current layer will be changed to the new layer. Other objects will remain on their original layer.

This variable tracks the state of the radio buttons in the Layer Change Mode pop-up, which appears when the Set Layer Chg Mode button in the Modify Menu is pressed.

JoinMaxPolyVerts
Value: integer 0 or 20-8000.
This variable applies to the Join and Join All buttons in the Join or Split Objects panel (from the Edit Menu), the !join command, the join (merging) operation when new objects are created, and the associated script functions and elsewhere where join operations occur.

This sets an upper bound on the number of vertices in polygons created by a join operation. The default is 600 vertices. If set to 0, no limit is applied. The variable tracks the Maximum vertices in joined polygon entry in the Join or Split Objects panel.

There is no internal limit on the vertex count of a polygon in memory. Although setting JoinMaxPolyVerts to 0 allows arbitrarily large polygons to be created, one should be reasonable. Huge polygons can be cumbersome and inefficient. Oversize polygons and wires will be broken up, if necessary, when a file is saved to disk. For the different formats, the limits are

native	no limit
CIF	no limit
CGX	8000 vertices
GDSII	depends on GdsOutLevel, max is 8000 vertices
OASIS	no limit

For CIF files, Xic can read/write arbitrarily large polygons and wires, but beware that other tools may have built-in limits.

JoinMaxPolyGroup
Value: integer >= 0.
This variable applies to the Join and Join All buttons in the Join or Split Objects panel (from the Edit Menu), the !join command, the join (merging) operation when new objects are created, and the associated script functions and elsewhere where join operations occur.

When a collection of trapezoids is being combined into polygons during a join operation, the collection is first divided into connected groups, each of which will be converted to one or more polygons. This variable limits the number of trapezoids in the groups. The default value (when this variable is unset) is 0, meaning that there is no limit. Generally, applying a limit (for example, 300) provides faster join operations, however this will leave as separate objects more polygons that could have been joined.

This variable tracks the Maximum trapezoids per poly for join entry in the Join or Split Objects panel.

JoinMaxPolyQueue
Value: integer >= 0.
This variable applies to the Join and Join All buttons in the Join or Split Objects panel (from the Edit Menu), the !join command, the join (merging) operation when new objects are created, and the associated script functions and elsewhere where join operations occur.

When objects are being joined, they are first decomposed into trapezoids. The trapezoids from the objects are saved in a single list, and when the list length exceeds a certain value the list is sent to the function that recombines the trapezoids into polygons. This variable is used to set the length threshold. The default value (when this variable is unset) is 0, which allows the list to grow without bound. Generally, applying a limit (for example, 1000) provides faster processing, but will produce more polygons.

This variable tracks the Trapezoid queue size for join entry in the Join or Split Objects panel.

JoinBreakClean
Value: boolean.
This variable applies to the Join and Join All buttons in the Join or Split Objects panel (from the Edit Menu), the !join command, the join (merging) operation when new objects are created, and the associated script functions and elsewhere where join operations occur.

In a join operation, when building up the polygons and the vertex limit (JoinMaxPolyVerts) is reached, ordinarily the present polygon is output, and a new one is started immediately. This generally produces a set of polygons with complicated and seemingly arbitrary borders. If this variable is set, then the polygons are initially built ignoring the vertex limit, and polygons that exceed the vertex limit are split into pieces along Manhattan bisectors, so that no piece exceeds the vertex count. This gives a much nicer looking layout, but is more compute intensive.

This variable tracks the Clean break in join operation limiting check box in the Join or Split Objects panel.

JoinSplitWires
Value: boolean.
This applies to join operations as listed for the variables above, but not for the joining when new objects are created. It also applies to the split operation.

By default, wires do not participate in join/split operations, these operate on boxes and polygons only. Wires, however, will be joined with other wires on the same layer it they share an endpoint and have the same width. If this variable is set, then wires will be treated like polygons in join and split operations, but wires never participate in the join operation when new objects are created.

This variable tracks the Include wires (as polygons) in join/split check box in the Join or Split Objects panel.

PartitionSize
Value: floating-point number.
This variable applies to layer expression evaluation, including from the Evaluate Layer Expression panel (from the Edit Menu), the !layer and !compare commands, and the AdvanceZref script function.

In releases prior to 3.0.0, this variable was named ``LayerPartSize''.

When geometrical operations are performed over a large area, a logical square grid is created over the area relative to the lower-left corner. The operations are performed for each grid element that intersects the area, and the results are combined. This can be more efficient than performing the operations over the entire area in one shot. Performance rapidly degrades as the amount of geometry per grid area increases. Best performance is probably obtained with 10000 or fewer trapezoids per grid.

This variable specifies the size of the grid, in microns, set as a floating-point number. If not set, the default grid size is 100 microns. Acceptable values are 1.0 - 10000.0, or 0. If set to 0, partitioning is not used.

The variable tracks the Partition size set in the Evaluate Layer Expression panel.

Threads
Value: integer 0-31.
PRELIMINARY, EXPERIMENTAL!

This will enable new multi-threaded functionality as it becomes available. This is set to the number of helper threads that can be called upon to parallelize certain operations. The best value is probably one less than twice the number of available processor cores. It should not be set to a larger value, but one might wish to try smaller values. If unset, or set to 0, the program is single threaded.

This variable tracks the Number of helper threads entry in the Evaluate Layer Expression panel from the Edit Menu.

Presently, multi-threading is used when evaluating a layer expression using a grid. Evaluation in each of the grid cells can be done in parallel, so these jobs are submitted to the thread pool. One can experiment with the partition size to get fastest results, larger partitions are more likely to overcome the multi-threading overhead.