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
case.
Comments