search

lh3 / miniasm

Ultrafast de novo assembly for long noisy reads (though having no consensus step)
MIT License
296 stars 68 forks source link

Hello there, #76

Open shehongbing opened 4 years ago

shehongbing commented 4 years ago

Hello there,

I had the exact same issue. Minimap2 worked fine but miniasm does not produce any output for some particular fastq file without any further indications. Did you solved your problem in the mean time ?

Cheers,

Roxane

Originally posted by @RxLoutre in https://github.com/lh3/miniasm/issues/50#issuecomment-417225754

sjfleck commented 4 years ago

Hi, I'm having the same issue. I'm rerunning a job that worked successfully in July, but is now failing to get past the very first step in Miniasm ([M::main] ===> Step 1: reading read mappings <===). Any help with this issue would be greatly appreciated.

SabSN commented 4 years ago

Hi, I'm having this issue too, where Miniasm stops at step 1. Seems that many have this issue, but no one really have a solution. Some say it is a problem in the self-mapping process. If anyone can help with this problem, I (and my lab) would appreciate it.

sjfleck commented 4 years ago

The weird thing for me is that I've successfully run this exact assembly before. This is what I'm doing:

minimap2 -x ava-ont -r 10000 -t 16 reads.fastq.gz reads.fastq.gz > overlap.paf miniasm reads.fastq.gz overlap.paf.gz > reads.gfa

The only insight I have is that my .paf file generated from minimap2 is different from before and I don't know what I did differently. About 6 months ago, my .paf file was only 1,631.2 GB, but when I run the same code with the same reads I get a .paf file that is 3,498.7 GB. I'm thinking that my issue is stemming from minimap2 and not miniasm. If either of you have found a solution to this, I would appreciate your insight.