It looks like you're new here. If you want to get involved, click one of these buttons!
Referring to some recently asked questions I would like to explain why KLayout operates
in two modes: the viewer and editor mode. This topic is also of interest for RBA users
since the mode choosen disables or enables certain functionality in the RBA interface and
requires some considerations when creating layout.
Basically, the distinction between the modes is made to allow a couple of optimizations in
the layout database which are specific for a certain use case.
For example: OASIS achieves a remarkable degree of compression by providing shape arrays:
a shape can be repeated many times. This saves space since the shape must be defined only
once and each repetition is described by just a displacement vector. In addition, OASIS
offers regular repetitions: if the same shape is arranged in a regular array, the whole
array can be described by a few parameters: row and columns displacements and counts. This
feature allows to squeeze a huge number of geometries into a few bytes. When reading OASIS
files, KLayout internally stores such arrays as such to benefit from the
compression effect and reduce the memory footprint.
Doing so is a good idea for a viewer. However, in an editor, using shape arrays creates
dependencies which are hard to understand for the user: by editing a shape of the array one
could modify other instances of the array as well. Since there usually is no semantical
connection between the instances of a shape array, this side effect is not desired.
One could mitigate the effect by dynamically resolving arrays but this would create a
number of algorithmic problems, i.e. with references that are held on single instances of
an array which is about to be dissolved.
Because of this, KLayout is not keeping OASIS shape arrays when operating in editor mode, which
increases memory consumption.
There are some more differences between these modes related to the way shapes and instances
are stored and how the storage containers behave upon modifications. Generally speaking, the
database is optimized for high performance and low memory foodprint in viewer mode and
for modification access in editor mode.
This has some consequences for RBA users as well. Here are two rules of thumb what mode to choose and
what to do in which mode:
In viewer mode, it is safe to either create a layout (new/insert/add operations) or to read it.
Insertion and query operations should not be mixed.
In editor mode, it is safe to read, insert and modify in any order. The layout database if fairly safe with
respect to modifications of items with references on them. The references will usually become invalid in this