GDS/OAS Save As with different DBU ~ issue?

Hi Matthias,

I noticed something weird (KLayout 0.27.10):

1) Original file with DBU = 0.00005: TEST2.gds
2) Saving as OAS file with the same DBU: TEST2.oas
3) Saving original file "TEST2.gds" as GDS file with DBU = 0.0001: TEST2_DBU_0p1nm.gds
4) Saving file "TEST2.oas" as OAS file with DBU = 0.0001: TEST2_DBU_0p1nm.oas

Files "TEST2.gds" and "TEST2.oas" are geometrically identical, as expected.

But files "TEST2_DBU_0p1nm.gds" and "TEST2_DBU_0p1nm.oas" are not geometrically identical. It seems the snapping to the new DBU is different for GDS and OAS files. The GDS versions looks ok (snapping to larger DBU as expected), but in the OAS version some small 0.1nm gaps appear, for instance in the "6" character.

Can you reproduce?




  • Hi Thomas,

    yes, I can reproduce the problem.

    Basically snapping is different between GDS and OASIS as for GDS all objects are polygons while for OASIS there are boxes and polygons and snapping happens differently for boxes. Basically KLayout does not give a warranty about snapping in a certain direction during write and BTW also not for reading (e.g. when translating off-grid array instances).

    Proper snapping is a complex topic in the general case. DRC has a feature for this. If you use a DRC script like this:

    inp = input(9001, 6)
    inp.snapped(0.1.nm).output(9001, 600)  # output

    Snapping will happen in a well defined manner. This code implies polygon merging. If you don't want to have this, use "raw" polygon mode:

    inp = input(9001, 6)
    inp.raw.snapped(0.1.nm).output(9001, 600)  # output

    If you save such a file with a 0.1nm database unit, the writer does not need to snap anymore.

    This solution will flatten your layout. If you intend to keep the hierarchy there is a method you can use from a Python or Ruby script which executes some elaborate algorithm to perform hierarchically correct ("as if flat") snapping and scaling. You can scale down your layout by half and then set DBU to double the value.

    Like this (Python, disclaimer: not tested)

    ly = pya.Layout()"original.gds")
    ly.scale_and_snap(ly.top_cell(), 1, 1, 2)  # scale by 1/2, snap to grid of 1
    ly.dbu = ly.dbu * 2.0"new_dbu.gds")


  • Hi Matthias,

    Thanks for your reply!

    I looked a bit deeper in the OAS file and noticed the same thing in the letter "P", where the two shapes are polygons, so still something weird going on with OAS format. So for now I suggest, without scripting (many people are terrified of that word):

    1) Merge the shapes of the OAS file before doing File > Save As OAS with the new DBU


    2) Save the OAS file as GDS with the new DBU, save the GDS back to OAS :-0

    I will test your script solution soon...



  • edited March 2

    Hi Thomas,

    I would not call that weird behavior of OASIS. OASIS has a much more elaborate concept than GDS for storing shapes. Like repetitions which duplicate a shape rather than producing it again. Also, polygon edges are represented in differential fashion (deltas). This all may lead to different ways of rounding.

    Again: The rounding details of OASIS or GDS writer are not specified. The DBU scaling is intended for upscaling (e.g. going from 1nm to 0.5nm) or when your layout is on grid already. When you want to scale down safely, use the provided, specified algorithms.

    There is nothing scary about scripting. This little fella will scale the currently loaded layout to twice the DBU:

    ly =
    ly.scale_and_snap(ly.top_cell(), 1, 1, 2)  # scale by 1/2, snap to grid of 1
    ly.dbu = ly.dbu * 2.0

    Save this as a macro, configure it to show in the menu ("Macro Properties") and you will have a new menu entry that does that snap and scale to twice the DBU.

    If your layout is flat (no hierarchy), you can also use the "Edit/Layout/Scaling" feature. Scale by 0.5 and edit the DBU in "Layout Properties" (do not use a different DBU in the writer options) to achieve the same result.

    You're right in a way that this behavior should be clearer. I imagine a warning in the UI when you are trying to scale down. Also, the "snap and scale" function could be made available through the user interface in Edti mode. I created a ticket on GitHub as a reminder for this topic: Please feel free to comment there.


  • Hi Matthias,

    Thanks for the clarification. "Weird" as in: I expected points with the same coordinates to snap to the same new point...

    I'm not really that scared of scripting (anymore ;-), but many colleagues run away as fast as they can if I mention scripting, lol...

    Attached a small script which does the job as expected for any given new DBU...



  • Understood - I need to add "Scale and snap" as a UI feature :)

    Side note: "scale and snap" is too heavy - and has side effects such as generating cell variants - to become included in the writer. I'll deprecate downscaling / snapping in the writer - actually there is a high risk to spoil things and you really need to know what you're doing when you use that feature.



Sign In or Register to comment.