[ymc]

I read the two papers more carefully and noted the versions of Chemistry, Sequencing Kit and Metrichor for each run:

ERX593921 is (R7.3, SQK-MAP-003, Metrichor 1.2.2 r1.5)
ERX708228 is (R7.3, SQK-MAP-003, Metrichor 1.9)
ERX708229-31 is (R7.3, SQK-MAP-003, Metrichor 1.9)

So the difference was due to using older version of Metrichor for ERX593921?

Does each run correspond to one ONT box? If that's the case we are only getting 133.6Mb for $4,000? Then ONT is not competitive at all in bacterial de novo assembly, right?

[ymc]

The ERX708228-31 data seems to have much higher yield for 2D reads than ERX593921. Why is that? Don't they all have the same R7.3 Chemistry? Or some sort of filter was applied for ERX708228-31? If so, what was that filter?

Archive #read length #2Dread length 2Dyield
593921 70531 311.56M 11823 64.53M 20.71%
708228 25353 150.33M 8451 52.26M 34.76%
708229 16917 61.57M 5639 21.91M 35.58%
708230 8565 46.05M 2855 16M 34.74%
708231 15975 123.29M 5325 43.44M 35.24%

[ymc]

Oh well, I figured it out.

I used ERX593921 data to polish the sample data which is from ERX708228 to ERX708231. After I used the fast5 from the correct archive, I was able to complete the run: (REF=polished, QRY=K12_MG1655)

[REF] [QRY]
[Sequences]
TotalSeqs 1 1
AlignedSeqs 1(100.00%) 1(100.00%)
UnalignedSeqs 0(0.00%) 0(0.00%)

[Bases]
TotalBases 4614015 4641652
AlignedBases 4612566(99.97%) 4620207(99.54%)
UnalignedBases 1449(0.03%) 21445(0.46%)

[Alignments]
1-to-1 86 86
TotalLength 4613201 4627972
AvgLength 53641.87 53813.63
AvgIdentity 99.23 99.23

I think better error messages in this case will be welcomed.

[ymc]

Dear all nanopore vets,

I just started looking into nanopore data. I set-up the PBcR pipeline and experimented with the sample data at the PBcR home page. It worked as expected.

The page mentioned that the assembly can be improved using nanopolish, so I downloaded Nick's fast5 and gave it try. Nanopolish took 25x time comparing to the PBcR pipeline. Is that normal? Can it be faster? I was running -P 6 for parallel and -t 6 for nanopolish on my 6-core machine.

I also noticed that two of the nanopolish threads crashed with the same assertion error:
nanopolish: src/hmm/nanopolish_profile_hmm.cpp:143: std::vector<AlignmentState> profile_hmm_align(const string&, const HMMInputData&): Assertion 'get(vm, row, col) != -(__builtin_inff())' failed.

When I tried to run nanopolish_merge.py, I got the following errors:
ERROR_MISSING ctg7180000000001 287
ERROR_MISSING ctg7180000000001 288
ERROR_MISSING ctg7180000000001 289
ERROR_MISSING ctg7180000000001 353
ERROR_MISSING ctg7180000000001 354
ERROR_MISSING ctg7180000000001 355
ERROR_MISSING ctg7180000000001 356
ERROR_MISSING ctg7180000000001 357
ERROR_MISSING ctg7180000000001 358
ERROR_MISSING ctg7180000000001 359

I think this was caused by crashing in two of the threads. Is it possible for me to rerun only crashed parts instead of the whole thing?

Thanks a lot in advance.

[nickloman]

Reminds me of this. I think at the time it was targeted at PacBio, but the author seems to have changed their mind since then.

http://pathogenomics.bham.ac.uk/blog...ring-shtseqtm/

Actually Neil Hall wrote that, I was just hosting for him. And he changed his mind because he bought a PacBio

[Brian Bushnell]

That was pretty funny

[BBoy]

There's paper in press claiming that using ONT data in combination with Illumina improves assembly quality ten fold.

Reminds me of this. I think at the time it was targeted at PacBio, but the author seems to have changed their mind since then.

http://pathogenomics.bham.ac.uk/blog/2012/02/a-new-sequencing-technology-enters-the-ring-shtseqtm/

[Brian Bushnell]

I agree that ONT is unlikely to supersede Illumina for quantification in the short term, but in the long term, it's possible. Illumina coverage does not reflect physical coverage, due mainly to its GC bias, but probably others. When you consider PacBio data - it's wonderfully smooth and unbiased, thus capable of accurately quantifying expression. Illumina is not capable of that on an absolute scale, though it should be accurate on a relative scale, between different samples considering the same gene isoform.

If Nanopore data is unbiased, the technology should allow you to fragment and sequence short reads (which are more applicable for quantification of unspliced genes) and get a superior result, compared to sequencing with known unpredictable biases. Currently ONT's error rate appears to be higher toward the beginning of a read, which would reduce the accuracy of short reads. But I think that single-molecule-sequencing is the way forward for absolute quantification or when dealing with alternatively-spliced genes; even if the reads have lower accuracy, as long as you can map them, you can greatly reduce bias and vastly increase your ability to identify isoforms, in one fell swoop.

Note that I am not presently allowed (by JGI) to give nonpositive ONT results. That said, I would like to say that their base-calling accuracy is advancing rapidly, and their read lengths are very impressive, greater than anything I've seen from PacBio. That alone has lead me to suggest using ONT for scaffolding, where it could allow great increases in genome contiguity, particularly in repetitive organisms..

[robp]

Hi ymc,

Certainly in the short term, I don't think that long read technology will replace Illumnia-style technology for quantification. The problems tackled by long reads are different. It may be great (once we can get the accuracy up) for isoform resolution, but the sheer number of reads is currently too small to be useful for many forms of quantification.

[ymc]

Do you guys think ONT can replace Illumina in the quantitation space? I think Illumina's fixed length reads probably is more suitable for quantitation, right?

[lkral]

If anyone in the MAP can talk about this, how does one prepare samples forMinION cDNA reads? Is it possible to get the entire length of the transcript sequenced or does the cDNA have to be fragmented during the sample prep? Thanks.

[ymc]

Hi Minion users, do you need to treat the samples with DNase to do viral sequencing? I learned it was necessary to do so with Illumina machines.

Thanks in advance for your reply

[Brian Bushnell]

I started a thread here containing an analysis of some of our NextSeq data, with HiSeq 2000 for comparison.

[Brian Bushnell]

This isn't really the place to discuss this (though I did bring it up); perhaps it should be moved to the Illumina forum? But anyway, tomorrow I'll post some of my NextSeq graphs. They have a very badly skewed A/T ratio that gets worse toward the read end. I'm not sure why; I had assumed it was the base caller, but it could be the chemistry. The C/G ratio seems fine.

[nucacidhunter]

I wonder if incorporation of G instead of A during sequencing with NextSeq as proposed by seqsence would explain the observation posted in this tread: http://seqanswers.com/forums/showthr...hlight=nextseq

poly-G in NextSeq
________________________________________
Hi,
I just received NextSeq paired-end results (45 bp 1st read and 40 bp second read) and I noticed (using FastQC) that about 1-2% of the second read is poly-G. I known that G has no "colour" so it probably means that these spots are not detected in the paired run but what is the cause for that? Is it common to get this number of failing paired reads? Have someone ran into this before?
Thanks
By the way, the first read also contains poly-G but for very few reads.

Has anyone observed similar results?