Open ipstone opened 6 years ago
Thanks! Glad it's usually fast. When it's not, I first suspect that there are a lot of discordant reads, which is causing it to do a lot of mate-region look-ups. It could also be that there are just a lot of low-quality reads with enough mismatches that it is causing a lot of clipping or unmapped reads, in which case the assembler is taking more time because it is assembling so many reads.
You might try the minimum number of discordant reads needed to trigger a mate-region lookup. This can be set with -L
(introduced < 1 year ago, so you need newer version). Seting -L 100000
effectively turns off mate-region lookup, which isn't terrible it just decreases the number of reads that get assembled together for true variants. You could also change the maximum number of reads that can be assembled at once (-x
). The default is 50,000, but this is a very very high number of reads and hitting that limit usually means that you're in a very difficult territory to map.
Also the regions you're showing me are in the non-chromosomal regions of the reference. I usually just skip these. You can set the regions -k
to be a BED file defining just the mappable, chromosomal regions of the genome.
Svaba is awesome! For frozen WGS samples, we got a genome done within 4-5 hours with low CPU/memory footage.
However, as we run tumor-normal pairs on FFPE samples,it is taking extra long time and not finishing. Is there a way to deal with the FFPE tumor-pair samples using svaba? Suggestions are really appreciated.
Here are some of the log information I have: The first number is the line number of the sample.log:
The error log of the job (the one killed before) looks like this: