Ouch: found 0 coverage
Brought to you by:
bach
Menu
▾
▴
#7 Ouch: found 0 coverage
mira gracefully gave up after encountering an :
//an hint on what happened would be nice//
Internal logic/programming/debugging error (sigh this should not have happened).
- Ouch: found 0 coverage in AL2012-FE_5ug_dn_rep_c77744 at position 3155 *
->Thrown: void Contig::reduceReadsAtCoveragePeaks(ccctype_t avgcov, vector<uint8> & peakindicator, unordered_set<readid_t> & readsremoved)
->Caught: main
//
//
Thank you for noticing that this is NOT a crash, but a
controlled program stop.
Failure, wrapped MIRA process aborted.
in this context :
MIRA 4.0rc4
On: Linux vk10464 2.6.32-41-generic #94-Ubuntu SMP Fri Jul 6 18:00:34 UTC 2012 x86_64 GNU/Linux
8 CPU + 102Gb RAM
40x106 solexa end-paired solexa reads in fastqformatted file = 14.1 Gb
Manifest:
projectname: AL2012-FE_5ug
job: genome,denovo
parameters: COMMON_SETTINGS -GENERAL:number_of_threads=8, -NW:cmrnl=no, -NW:cnfs=no ,-HS:ldn=yes,-DIR:trt=////tmp SOLEXA_SETTINGS -AL
IGN:min_score=10 , bip=30
Am I correctly reading some slight irony in your comment? :-)
What you stumbled upon is a that MIRA found out that it maneuvered itself into an impossible state (due a bug somewhere in the program) and decided to stop things immediately. The error messages in those cases may be cryptic to the end-user I agree, but sufficient for me while debugging. Had the problem been provoked by a probable user or data error, the message would have been much more userfriendly.
Back to your problem: is the bug reproducible if you resume the assembly (-r option)? If yes, it would be worthwhile for me to go on a hunt with parts of your data if possible.
On 14 janv. 2014, at 22:30, Bastien Chevreux bach@users.sf.net wrote:
ok sorry for the perceived irony , there's on hard feelings feelings at all.
i was just desperately struggling with hardware problems and got struck back by software ones ! it’s so frustrating ..
i’ll get back to you tomorrow with more feedback, but yes the bug is reproducible upon resuming the assembly
thanks for your concern
Yvan
Related
Tickets:
#7Hi,
i've done several test assemblies yesterday after looking thru the log and output files, but to little avail
my current working dataset is 40.10x6 paired reads (as paired with PANDAseq)
the data is from environmental sampling, Illumina HiSeq
so i tried:
an attempt with 1.10x6 reads => success ; but that's useless
next with 5.10x6 reads => fail (throwing 'Ouch: found 0 coverage' )
next removed ard (-AS:ard=no)
assembled 5.10x6 reads => fail (same as above )
next instead of using PANDAseq paired reads i used forw & rev reads + autopairing
assembled 5.10x6 reads => fail (same as above )
next, i though maybe my dataset is the culprit. so i took another one (but provided by the same sequencing contractor / same technology )
so i assembled 5.10x6 reads => fail (same as above )
moreover towards log's end i found every time this pretty scary warning:
lastly, i tried also to assemble 5.10x6 reads with mira_3.2, but it failed alike, although in a different way (it crashed during an alignment step)
there are so many places to look for in output files, where should i start next,
or do you want me to hand you some specific files ?
my worst guess is that something went horribly wrong during sample dna libraries preparation and/or sequencing, but in this case how to ascertain it?
thanks for an advice
Yvan
Hmmm, strange. Good, two things:
1. thank you for creating a smaller data set in case point 2 fails, I'll certainly take that as fallback option.
2. Just for laughs, could you please try with 4.0rc5? You are using rc4 atm and ... well, maybe that problem has been fixed
I am crossing fingers here ...
B.
Any news on whether the error is still present in 4.0rc5? I'm wrapping up things for the release of 4.0 and would like to be as sure as possible that show stoppers like the bug above are gone.
except for the first run which was 4.0rc4 all others were with 4.0rc5 ...
this was an unsuccessful attempt at doing metagenome assembly with mira, but obviously it isn't prepared for that
Y.
If you could upload to Dropbox one of the small test sets which failed and then send me the link to my private email, I'll have a look at it this evening. Please also include the manifest file you are using.
BTW, the error you are seeing has nothing to do with metagenomic data in itself. The data set just seems to trigger a bug which apparently never shows otherwise.
The problem you are seeing indeed comes from something I had not foreseen: using digital normalisation together with genome assembly routines (instead of EST/RNASeq). I will take care that the next release of MIRA will not stumble across that.
In the mean time (and if you want to use digital normalisation with the genome assembly setting), you can use the following parameter to help you out:
-MI:ef2=no
Hope that helps, feedback appreciated.
Any news on this ticket? If not, I'll close it.
Closed as no further feedback provided.