[mira_talk] BUG Nasty Repeats?

  • From: Adrian Pelin <apelin20@xxxxxxxxx>
  • To: "mira_talk@xxxxxxxxxxxxx" <mira_talk@xxxxxxxxxxxxx>
  • Date: Sun, 20 Mar 2016 16:33:42 -0400

Hello,

I got this odd message saying 0 percent of reads are nasty repeats:

-------- MINOR warning --------

MIRA warncode: UNASSEMBLED_NASTYREPEATS
Title: Reads with masked nasty repeats landed in debris file

There are 0 of your reads (~1035786%) containing so many bases masked as
nasty
repeats that the SKIM fast overlap finder did not return enough results.
If you want those reads to be found (and subsequently assembled), you need
to
either
- switch off masking of nasty repeats (-HS:mnr=no)
- increase the the nasty repeat ratio (-HS:nrr=...) (consult the hash
  statistics in the output log of MIRA to find a good one)
Beware! Masking of nasty repeats is the second defense mechanism of MIRA
(after
megahubs) to keep assembly times reasonable. Changing the defaults will
increase
the time needed. Fortunately, the number of completely masked reads is low
enough to safely switch off masking.

Buildstats - RM positions        :    24443    53246
Buildstats - overcall edits      :    0    0
Buildstats - hash edits          :    5688    13602
Buildstats - contig disassemblies:    0    0

__________________________

Manifest file:

project = mira_merged_sample50X_try1
job = genome,denovo,accurate
parameters = -GE:not=8:kpmf=15:
parameters = -NW:cmrnl=no
parameters = -NW:cac=warn
parameters = -NW:cnfs=warn

readgroup = SomePairedEndIlluminaReadsIGotFromTheLab
data = GDR-24_merged_sample50X.fastq
technology = solexa

Any idea what could be happening?

This is a Nextera Library, back from a few years ago. MiSeq 250bp x2, reads
were merged since fragment size was barely 300bp.

Adrian

Other related posts: