The Trinity suite has options for genome guided RNASeq assembly. http://trinityrnaseq.sourceforge.net/#genome_guided
Why would this be advantageous compared to the tophat-cufflinks pipeline? If the reads come from the genome, why not just map to known and novel exons, rather than assembling de-novo?
Also, it seems that the genome is just used to partition the reads. Does this mean that the unmapped reads are discarded, or do they just form another partition?
It says:
and,
Why would this be advantageous compared to the tophat-cufflinks pipeline? If the reads come from the genome, why not just map to known and novel exons, rather than assembling de-novo?
Also, it seems that the genome is just used to partition the reads. Does this mean that the unmapped reads are discarded, or do they just form another partition?
It says:
If a genome sequence is available, Trinity offers a method whereby reads are first aligned to the genome, partitioned according to locus, followed by de novo transcriptome assembly at each locus.
In summary, the genome-guided Trinity involves two major phases. The first phase involves partitioning genome-aligned reads into subsets that will each be targeted for independent Trinity de novo assembly.
This first phase of either aligning reads (or using an existing coordinate-sorted bam file) happens on a single server, runs multithreaded, and leverages the parameters:
--genome <string> (ie. genome.fasta)
--genome_guided_max_intron <int> (ie. '10000')
--genome_guided_sort_buffer <string> (ie. '10G')
--CPU <int> (ie. 10)
--GMAP_CPU <int> (ie. 10, defaults to --CPU setting)
or use: --genome_guided_use_bam <string> (ie. gsnap.coordSorted.bam)
The second phase involves running Trinity de novo assembly on each of the partitioned sets of reads. If you end up with tens of thousands or hundreds of thousands of sets of partitioned reads, this means that you’ll have that large number of de novo assemblies to execute (in parallel). Each of these parallel-executed commands leverages the parameters:
--genome_guided_CPU <int> (ie. 4, *beware* that this defaults to --CPU)
--JM <string> (ie. '2G', note that not much RAM is required for assembly of these relative small sets of reads)
This first phase of either aligning reads (or using an existing coordinate-sorted bam file) happens on a single server, runs multithreaded, and leverages the parameters:
--genome <string> (ie. genome.fasta)
--genome_guided_max_intron <int> (ie. '10000')
--genome_guided_sort_buffer <string> (ie. '10G')
--CPU <int> (ie. 10)
--GMAP_CPU <int> (ie. 10, defaults to --CPU setting)
or use: --genome_guided_use_bam <string> (ie. gsnap.coordSorted.bam)
The second phase involves running Trinity de novo assembly on each of the partitioned sets of reads. If you end up with tens of thousands or hundreds of thousands of sets of partitioned reads, this means that you’ll have that large number of de novo assemblies to execute (in parallel). Each of these parallel-executed commands leverages the parameters:
--genome_guided_CPU <int> (ie. 4, *beware* that this defaults to --CPU)
--JM <string> (ie. '2G', note that not much RAM is required for assembly of these relative small sets of reads)
