ENA minion 2D data doesn't actually have 2D data

Question

I am looking at some yeast ONT data from De novo yeast genome assemblies from MinION, PacBio and MiSeq platforms, Giordano et al 2017.

I noticed that the Minion fastq files have both a forward and reverse file. The methods paper says that these reads are from the SQK-MAP006 and SQK-MAP007 protocols which both appear to be 2D. Are these just the 2D forward and reverse files?

Still being unsure, I checked if this was true by counting the number of characters in each read.

>> zcat ERR1883385_1.fastq.gz | head -1
@ERR1883385.1 dc5b9de2-ba00-47ab-b698-8ad470704c0a_Basecall_2D_000_template EVO107591_Sanger_FAA52213_CBS432_Phenol_3a_4517_1_ch251_file44_strand/1

>> zcat ERR1883385_2.fastq.gz | head -1
@ERR1883385.1 dc5b9de2-ba00-47ab-b698-8ad470704c0a_Basecall_2D_000_template EVO107591_Sanger_FAA52213_CBS432_Phenol_3a_4517_1_ch251_file44_strand/2


>> zcat ERR1883385_1.fastq.gz | head -2 | awk '{ print length($0); }' -
147
1675

>> zcat ERR1883385_2.fastq.gz | head -2 | awk '{ print length($0); }' -
147
1693

As you can see, the read is the same but the forward and reverse strands are different lengths.

Is there some way to just download the poretools equivalent to 2D from ENA without having to download the fast5 files and extract them myself?

Answer 1

Probably not. ENA doesn't have any ability to specifically flag a file as 2D, and the nanopore file formats have changed a lot, so you pretty much need to rely on the submitter to separate out the reads in a meaningful way.

Also, there wasn't really any consistent convention for what ONT used in their read headers. Looking at some of my old files they had a plain sequence ID (i.e. without anything suggesting temp/comp) in different template/complement folders in the FAST5 files for the components of a 2D read and the consensus sequence, but later changed it to _2D_template and _2D_complement as in the example you have (possibly with an intermediate _1D_template and _1D_complement format). Parsing/understanding those FAST5 files can be difficult, which is why poretools was created in the first place.

It's still a bit of a mess, with the 1D$^2$ reads ending up in a Frankenstein-like state that's partially 1D and partially 2D.