layer boolean with 5000x5000 array. ERROR: std::bad_alloc?

WLNE

$ ulimit
unlimited

I have 4 3500x3500 arrays in my layout, on layer 6

2 of them need to be convert to negative feature. so I create 2 boxes larger than the array on layer 1. Then I try to do boolean XOR on layer 1 and 6. But I always get ERROR: std::bad_alloc.

if I try to flatten one of the instance it will eat up too much memory too. Any suggestion about this?

laurent_c

Hi WLNE,

Tiling is a method built into the DRC language and you can enable tiling by adding certain commands to the script. Please see http://www.klayout.de/doc/manual/drc_runsets.html#h2-639 for details.
Hope it should work. Rgds,

Laurent

WLNE

Hi Laurent,
Thanks a lot for the tips. The XOR tool I used already has the tile option. I were using 1000 micron tile size (about 50 circles in one tile).

However, it still eat up 30GB RAM and throw out the bad_alloc error. I tried 500 micron tile, which gave the same error. So I think this might has nothing to do with the tile.

First I thought, this might because one of the object is big enough. So the XOR might keep adding vertex into that object till the RAM got exploded. However, this is not the case, I try to use 1 very small object in another layout. The XOR still blew up the RAM. I think this is because the flatten operation embedded inside the XOR tool. Flatten 3500x3500 circles already cause the RAM issue.

I did a test, 3500x3500 circles will use >10GB RAM. I wonder if the algorithm support memmap/out-of-core to pull the shapes into memory tile by tile, then push the processed one back to the memap file might improve the XOR performance on large arrays.

arided

Hi, WLINE:
My experience is if the cell dimension greater than 5000 x 5000um or >2 billion polygons. The Boolean operation will need at least 120GB memory on using flat mode. For reducing the memory consumption, I recommend to use hierchy mode. If you indeed to use the flat mode, you may use "=nil" in ruby program after one layer operation done. Here is example
######################################
po = input("2/0")
ac = input("1/0")
tiles(10)
tile_borders(0)
threads(4)
gate = po.and(ac)
po=nil
ac=nil
## other code here ###########
#### code codes codessss
###############################
GC.start
gate=nil
no_borders
flat
#### end codes###################



arided

Matthias

Hi,

thanks for keeping the discussion going ... :-)

The basic reason for the memory problem is likely to be the generation of huge polygons, which happen to be created when you punch many holes from some background polygon. Tiling is a very good option to reduce that problem. As a rule of thumb, I'd try to avoid polygons with more than ~10000 points, so given your array consist of rectangles (4 points) each, a single tile should not cover more that ~2500 array elements (i.e. 50x50 array elements). So if your array pitch is 10 micron, the tile size should be about 500 micron. You can even go below that.

I just ran an example with a rectangle array of 3500x3500 array elements with 10 micron pitch. I used 100 micron tiles and this DRC script:

tiles(100)
(input(2)-input(1)).output(10)

(layer 1 is the rectangle array, layer 2 a big cover rectangle).

I ran about 60 seconds and no considerable memory use.

I have no feeling about your case, so I can just guess. Maybe the polygons are still too complex.

There is another option: if you are able to put the background layer into your array cell too (in a way that the combined background rectangles form a big area), the NOT operation can be performed locally on the array cell and that operations will cost almost no memory and CPU time.

Matthias