How can I minimize the size of GDS file?

edited September 2014 in General
A GDS file has been generated with the size of ~2G. To minimize the size of this file, I’ve tried to change the display settings, and it seemed no difference. Then I tried ‘save as’ button to get another GDS file with lower ‘database unit’, but the new file was even bigger. I am just wondering how to deal with the problem. Thanks a lot in advance!


  • edited November -1

    Hi yan,

    database oder or display settings do not change the size of the GDS file.

    You can compress the gile (select the "gzip" checkbox). That will give you a factor of 5 roughly.

    My definitive recommendation is to use OASIS format instead of GDS. OASIS gives a much smaller files. Sometimes the files are smaller by several orders of magnitudes.


  • yanyan
    edited November -1
    Hi Matthias,
    Many thanks for your kind advice. I do apologize for my unclear description before. My GDS file was calculated and generated by Matlab software, and the default resolution might be so high that the mask (GDS file) is difficult to be fabricated. By the way, the database unit is 1nm and pixel size is 1um. Therefore I would like to change the ‘data precision’ to match the real processing conditions (0.1um of plotting precision might be enough), and thus decrease the size of the file (hope so, but I have no idea how to do that). And I’ve discussed with the technicians of mask manufacture, it is said that the file of OASIS format could not be accepted… Would you please kindly offer me any further advice? Thank you very much again!
  • edited September 2014

    Hi Yan,

    I doubt that your mask maker has a technical reason to reject OASIS - OASIS is quite a common standard today, specifically in the mask making business. I see more reasons to reject GDS because of the sloppiness of the specification. I suspect they are looking for a reason to charge you some conversion fee.

    Nevertheless, as I said, changing the database unit will not change the file size.

    Let me explain: the GDS format stores the coordinates in integer units as multiplies of a common unit, which is the database unit. x/y coordinates, path widths, cell positions and so forth are all multiples of that unit and that is pretty good, since integer units are free of rounding and interpretation issues. OASIS uses that concept too with slight modifications.

    GDS uses 32 bit coordinates, so the coordinate space of your layout is limited to roughly -2e9 to 2e9 database units. In practice it's not safe to fully exploit that range but with KLayout you can safely use a window of -1e9 to 1e9 database units.

    1 nm is a pretty common database unit and I recommend to keep it. Your safe data window can be as big as 2x2 meters which should be sufficient for almost every application. In OASIS, there is not such limit, but KLayout still imposes that limitation for practical reasons (unless you build it with 64bit coordinate support).

    But I think that is not a topic here. Using 1 nm for the database unit does not mean your layout cannot be on a coarser grid. If your layout uses a construction grid of 0.1 micron, that just means you are using coordinates which are multiples of 100 (database units). Keeping 1 nm as a database unit provides you with some accuracy reserve in case you want to apply some operations later (boolean operations, biasing). That is important in particular if your layout has curved features - in that case, any postprocessing will introduce some kind of roughness in the order of the database unit. So having a small database unit creates some benefit here.

    Maybe it becomes clear now that the file size does not change for GDS - a 32 bit coordinate will always occupy 4 bytes, irregardless of the database unit. If you want to reduce the file size, the most effective way is to employ hierarchy. If you have features that are present multiple times, you can put them in a cell and place this cell. While placing you can apply rotation and mirroring too (even magnification, but that may induce rounding issues when snapping to the 100 nm grid finally). You can even create array instances, which create huge arrays of identical structures with a few bytes.

    Apart from that there are not many ways to reduce the GDS file size. If you have many cells you can try to keep the cell names short, but that won't save much. Compressing the final layout gives you a reduction of typically 5 to 6x, but that's it. Again, OASIS offers more features for file size reduction such as shape arrays and those are mainly responsible for the small files you typically get with OASIS.

    Hope that answer was helpful.



  • edited November -1

    I have used software below in a company i used to work for.
    It is designed specifically to compress GDS files and can compress by a factor of 10.
    But it is not cheap.

  • edited November -1
    Hi Mikamar,
    Do you know is there any open source library or softwares could handle mebes data?

  • edited November -1
    Hi Dion -

    No, not aware of such.

  • edited February 2015

    Hi all,

    the MEBES format is owned by Applied Materials (edit: not KLA Tencor as said before) and there seems to be little chance the will make it public.

    In case somebody from AMAT is reading this: drop me a note if I am wrong - I'm ready to support MEBES :-)


  • edited February 2015


    I am also interested in MEBES format because of mask jobView.

    I read on wikipedia the origin of MEBES format :,_Inc.

    Do you have some other news on that format ?



  • edited February 2015

    Hi Laurent,

    There is no magic about MEBES, but the format is NOT PUBLIC and every attempt to publish source code reading it is equivalent to disclosing the spec. I don't like to risk a lawsuit with AMAT.

    So MEBES won't go into GPL'd software (along with OpenAcess, which is also not compatible with GPL).

    I'm sorry, but these are the rules. Maybe OASIS will finally win over MEBES because of that.


Sign In or Register to comment.