The 'ont2d' flag sets up BWA parameters to work for ONT data. It was named at a time when 2D data was similar accuracy to what 1D data is at the moment. You should be fine using Albacore 2.0-called reads with the stated workflow.

The indexing process links the Fast5 files to the FASTQ records. Nanopolish uses this index and the FAST5 files to correct the reads during the polishing step.

First I am under the impression nanopolish uses raw fast5 files in order to polish but the initial step requires indexing of fastq files (albaore 2.0 step)

Like an earlier user mentioned, the initial indexing step links each read in the fastq file with a fast5 record.

Prior to basecalling with albacore 2, you would use

Code:

nanopolish extract

to make the fastq-to-fast5 links; nanopolish would extract the base-called fastq sequences from fast5 files and would I think add comments to each fastq read indicating which fast5 file it came from. Having the fastq string stored in the fast5 file can cause the latter to grow significantly; and once you extract the fastq strings they become redundant in the fast5 files, and you end up wasting system storage. The newer version of nanopolish has the

Code:

index

subcommand that makes fastq-to-fast5 links so that using nanopolish might look like this:

Run MinION without basecalling

Call bases with albacore v2+ to fastq format

Link fastq files to fast5 files with nanopolish index

... do additional stuff with nanopolish ...

Quote:

Originally Posted by anotherSAM

Secondly for the mapping stage 'bwa mem...', the only options are for ont2d data.

When are the fast5 files used if they are?
and how can I use nanopolish on 1D data?

Thanks in advance

I think that the fast5 files are used when you run the

Code:

nanopolish variants --consensus

command. I think that you provide the fastq file as an argument, and nanopolish will check whether index files exist for those reads (usually same base filename with some new extension added), similar to the files generated by

Code:

bwa index

. The index files provide an explicit filesystem mapping between each read in the fastq file and a fast5 file. I've never tried, but I think that nanopolish will fail if you move the fast5 files to another location in the filesystem after you've indexed the reads. If you did that, I think you'd have to re-index.