#7 Ouch: found 0 coverage

4.0rc5
closed
nobody
2014-09-28
2014-01-14
yvan zivanovic
No

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

Related

Tickets: #7

Discussion

1 2 > >> (Page 1 of 2)
  • 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.

     
    • yvan zivanovic
      yvan zivanovic
      2014-01-15

      On 14 janv. 2014, at 22:30, Bastien Chevreux bach@users.sf.net wrote:

      Am I correctly reading some slight irony in your comment? :-)

      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

      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.

      [tickets:#7] Ouch: found 0 coverage

      Status: open
      Labels: internal error
      Created: Tue Jan 14, 2014 10:00 AM UTC by yvan zivanovic
      Last Updated: Tue Jan 14, 2014 10:00 AM UTC
      Owner: nobody

      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 & peakindicator, unordered_set & 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

      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/mira-assembler/tickets/7/

      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

       

      Related

      Tickets: #7

  • yvan zivanovic
    yvan zivanovic
    2014-01-16

    Hi,

    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:

    -------- CRITICAL warning --------

    MIRA warncode: CONCOV_SUSPICIOUS_DISTRIBUTION
    Title: Suspicious distribution of contig coverages

    • 0 contig(s) with a total of 0 bases (= nan% of bases in all non-repetitive
      large contigs) have an average coverage less than 75% of the average coverage
      of all non-repetitive large contigs.
    • 0 contig(s) with a total of 0 bases (= nan% of bases in all non-repetitive
      contigs) have an average coverage more than 125% of the average coverage of
      all non-repetitive large contigs.
    • 0 contig(s) with a total of 0 bases (= nan% of bases in all non-repetitive
      contigs) have an average coverage 25% above or below the average coverage of
      all non-repetitive large contigs.

    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.

     
  • yvan zivanovic
    yvan zivanovic
    2014-01-27

    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.

     
1 2 > >> (Page 1 of 2)