[Bioperl-l] Next-gen modules
Chris Fields
cjfields at illinois.edu
Tue Jun 30 17:46:27 UTC 2009
On Jun 30, 2009, at 6:28 AM, Giles Weaver wrote:
> I'm developing a transcriptomics database for use with next-gen
> data, and
> have found processing the raw data to be a big hurdle.
>
> I'm a bit late in responding to this thread, so most issues have
> already
> been discussed. One thing that hasn't been mentioned is removal of
> adapters
> from raw Illumina sequence. This is a PITA, and I'm not aware of any
> well
> developed and documented open source software for removal of
> adapters (and
> poor quality sequence) from Illumina reads.
>
> My current Illumina sequence processing pipeline is an unholy mix of
> biopython, bioperl, pure perl, emboss and bowtie. Biopython for
> converting
> the Illumina fastq to Sanger fastq, bioperl to read the quality
> values, pure
> perl to trim the poor quality sequence from each read, and bioperl
> with
> emboss to remove the adapter sequence. I'm aware that the pipeline
> contains
> bugs and would like to simplify it, but at least it does work...
My local bioperl is working with FASTQ parsing of Sanger and Illumina
(but not solexa yet). I'll commit what I have today, and we should be
able to add in solexa soon. We'll also need to add in write_seq
support.
> Ideally I'd like to replace as much of the pipeline as possible with
> bioperl/bioperl-run, but this isn't currently possible due to both a
> lack of
> features and poor performance. I'm sure the features will come with
> time,
> but the performance is more of a concern to me. I wonder if
> Bio::Moose might
> be used to alleviate some of the performance issues? Might next-gen
> modules
> be an ideal guinea pig for Bio::Moose?
We should get FASTQ working in core first then optimize on speed (as
Elia previously pointed out). We can do that within the actual SeqIO
parser using a few simple tricks. For instance my local
Bio::SeqIO::fastq has a reconfigured next_seq to call an iterator that
returns raw processed data as a simple hash ref; users have access to
that method, so if one wanted they could retrieve the raw data
directly, or pass it through a filter that only creates seq instances
one wants on the fly (that would be where your quality checks, adaptor
modification, etc. fit in).
In the end it might be to wrap a C/C++-based solution for speed. As
mentioned previously a C-based parser exists from Sanger Centre that
we could incorporate in some fashion, but I would like if it were able
to report back file position for fast indexing. The code is fairly
simple so it should be too hard to incorporate that in somehow.
Just so there is no confusion, Bio::Moose is an attempt to both lay
out plans for perl6 and deal with inheritance issues within bioperl
now. It's still in very early development and may not see a release
until Dec. at the very earliest, it will be an alpha release then, and
likely won't have every major class represented at that point. It's
also not intended to be backwards-compatible with bioperl core. It
may help, but that's not an absolute certainty. As for bioperl6, it
will be pre-alpha until perl6 spec reaches a stable draft and we have
an active implementation.
> For my purposes the tools that would love to see supported in
> bioperl/bioperl-run are:
>
> - next-gen sequence quality parsing (to output phred scores)
> - sequence quality based trimming
> - sequencing adapter removal
> - filtering based on sequence complexity (repeats, entropy etc)
> - bioperl-run modules for bowtie etc.
>
> Obviously all of these need to be fast!
> I'd love to muck in, but I doubt I'll contribute much before
> Bio::Moose/bioperl6, as the (bio)perl object system gives me
> nightmares!
One can only read a file so fast (even with a highly optimized C/C++
based parser), but I don't think that will be the limiting factor as
much as object instantiation.
> Regarding trimming bad quality bases (see comments from Tristan
> Lefebure)
> from Solexa/Illumina reads, I did find a mixed pure/bioperl solution
> to be
> much faster than a primarily bioperl based implementation. I found
> Bio::Seq->subseq(a,b) and Bio::Seq->subqual(a,b) to be far too slow.
> My
> current code trims ~1300 sequences/second, including unzipping the
> raw data
> and converting it to sanger fastq with biopython. Processing an entire
> sequencing run with the whole pipeline takes in the region of 6-12h.
Right, hence coming up with a 'pre-filter' for raw data (hash refs)
prior to object instantiation to speed things up. This will be a bit
easier with Bio::Moose as we can introspect attributes via the meta
class, but this will be a while yet.
> Hope this looooong post was of interest to someone!
>
> Giles
It's always good to hear about such issues and what one expects.
chris
More information about the Bioperl-l
mailing list