ruanjue / wtdbg2

Redbean: A fuzzy Bruijn graph approach to long noisy reads assembly
GNU General Public License v3.0
504 stars 92 forks source link

Killing at Kmer scanning step #219

Open andreyurch opened 3 years ago

andreyurch commented 3 years ago

wtdbg2 -x ont -g 1.25g -i test.fq.gz -t 10 -fo wtdbg2test

-- total memory 131733680.0 kB -- available 111429804.0 kB -- 32 cores -- Starting program: wtdbg2 -x ont -g 1.25g -i test.fq.gz -t 10 -fo wtdbg2test --cpu 10 -- pid 25925 -- date Mon Dec 7 11:05:06 2020

[Mon Dec 7 11:05:06 2020] loading reads 338354 reads [Mon Dec 7 11:06:55 2020] Done, 338354 reads (>=5000 bp), 6123373697 bp, 23750561 bins PROC_STAT(0) : real 108.942 sec, user 103.690 sec, sys 3.170 sec, maxrss 1933652.0 kB, maxvsize 2243012.0 kB [Mon Dec 7 11:06:55 2020] Set --edge-cov to 2 KEY PARAMETERS: -k 0 -p 19 -K 1000.049988 -A -S 2.000000 -s 0.050000 -g 1250000000 -X 50.000000 -e 2 -L 5000 [Mon Dec 7 11:06:55 2020] generating nodes, 10 threads [Mon Dec 7 11:06:55 2020] indexing bins[(0,23750561)/23750561] (6080143616/6080143616 bp), 10 threads [Mon Dec 7 11:06:55 2020] - scanning kmers (K0P19S2.00) from 23750561 bins 1900000Killed

ruanjue commented 3 years ago

If the RAM was inadequate, try append -S 4 to wtdbg2.

andreyurch commented 3 years ago

I tried, did not help unfortunately.

ruanjue commented 3 years ago

The first question is why it was killed by system or administrator