This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
archive:bioinformatic_tools:abyss [2010/05/17 23:45] jstjohn |
archive:bioinformatic_tools:abyss [2010/05/19 17:46] jstjohn |
||
---|---|---|---|
Line 244: | Line 244: | ||
There is some error where the laneX.hist files are empty... | There is some error where the laneX.hist files are empty... | ||
- | |||
====Attempt 4==== | ====Attempt 4==== | ||
I have access to kolossus which has 1.1tb of ram. I will now run the program on kolossus to see if it will assemble there... | I have access to kolossus which has 1.1tb of ram. I will now run the program on kolossus to see if it will assemble there... | ||
Line 266: | Line 265: | ||
- | Note that this run combines both the illumina runs and the 454 data for banana slug. I am also experimenting with a k=35 since galt had better luck with a kmer size of 31 using SOAPdenovo than a kmer size of 23, perhaps the trend continues into larger kmers. If this doesn't work for whatever reason, I will also try shorter and longer kmers. | + | Note that this run combines both the illumina runs and the 454 data for banana slug. I am also experimenting with a k=35 since Galt had better luck with a kmer size of 31 using SOAPdenovo than a kmer size of 23, perhaps the trend continues into larger kmers. If this doesn't work for whatever reason, I will also try shorter and longer kmers. |
+ | |||
+ | We combined all fastq files into two large files representing the two read pairs. Each of these files is approximately 50GB and contain roughly 20GB of reads. Even on kolossus I am getting some out of disk space errors in the following step: | ||
+ | |||
+ | <code> | ||
+ | KAligner -j4 -k35 /scratch/galt/bananaSlug/slug_1.fastq /scratch/galt/bananaSlug/slug_2.fastq slugAbyss3-3.fa \ | ||
+ | |ParseAligns -k35 -h lib1-3.hist \ | ||
+ | |sort -nk2,2 \ | ||
+ | |gzip >lib1-3.pair.gz | ||
+ | </code> | ||
+ | |||
+ | Near the height I have observed this is eating up about 50G of ram, but the issue appears to be in available space for the sort algorithm in kolossus's /tmp/ directory. I am trying this again so I can copy down the error and send it to cluster-admin because kolossus should have around 400GB free of local HD space on top of its 1.1TB of ram. (kolossus has more ram than HD space: 1.1TB of ram vs 750GB hd) | ||