Question: Cuffmerge or Cuffcompare?!
0
gravatar for Xin
4.5 years ago by
Xin60
Xin60 wrote:

Hii 

For differential expression analysis, I'm using following protocol: 

FastQC => TopHat => Cufflinks => Cuffmerge => Cuffdiff => CummeRbund

  • I have two conditions, so I have two TopHat output folders.
  • I use accepted_hits.bam files as inputs for Cufflinks (I run cufflinks twice. One for each condition) . At the end of Cufflinks process I have these files: , transcripts.gtf, isoforms.fpkm_tracking and genes.fpkm_tracking for each condition.
  • Then I merge transcripts.gtf files of each condition and at the end of cuffmerge process I have a master transcriptome file.
  • Finally I use this master file and two accepted_hits.bam(TopHat outputs for each condition) for cuffdiff. and I analyse the results in cummerbund. 


I thought I'm right in calculating differential expression but just now I read in Rna-Seq With Cuffdiff: Use Merged.Gtf From Cuffmerge Or Combined.Gtf From Cuffcompare? "If you want differential expression, you should just use the combined.gtf from cuffcompare. by Mr Damian Kao" 

So am I wrong in calculating differential expression? 

rna-seq • 4.6k views
ADD COMMENTlink modified 4.5 years ago by Carlo Yague4.9k • written 4.5 years ago by Xin60
5
gravatar for Thibault D.
4.5 years ago by
Thibault D.690
European Union
Thibault D.690 wrote:

Hi, here is the copy of Trapnell response to a similar question in SeqAnswers (available here)

Cole Trapnell said :

I can shed some light on this. We have an upcoming protocol paper that describes our recommended workflow for TopHat and Cufflinks that discusses some of these issues.

As turnersd outlined, there are three strategies:

1) merge bams and assemble in a single run of Cufflinks
2) assemble each bam and cuffcompare them to get a combined.gtf
3) assemble each bam and cuffmerge them to get a merged.gtf

All three options work a little differently depending on whether you're also trying to integrate reference transcripts from UCSC or another annotation source.

#1 is quite different from #2 and #3, so I'll discuss its pros and cons first. The advantage here is simplicity of workflow. It's one Cufflinks run, so no need to worry about the details of the other programs. As turnersd mentions, you might also think this maximizes the accuracy of the resulting assembly, and that might be the case, but it also might not (for technical reasons that I don't want to get into right now). The disadvantage of this approach is that your computer might not be powerful enough to run it. More data and more isoforms means substantially more memory and running time. I haven't actually tried this on something like the human body map, but I would be very impressed and surprised if Cufflinks can deal with all of that on a machine owned by mere mortals.

#2 and #3 are very similar - both are designed to gracefully merge full-length and partial transcript assemblies without ever merging transfrags that disagree on splicing structure. Consider two transfrags, A and B, each with a couple exons. If A and B overlap, and they don't disagree on splicing structure, we can (and according to Cufflinks' assembly philosophy, we should) merge them. The difference between Cuffcompare and Cuffmerge is that Cuffcompare will only merge them if A is "contained" in B, or vice versa. That is, only if one of the transfrags is essentially redundant. Otherwise, they both get included. Cuffmerge on the other hand, will merge them if they overlap, and agree on splicing, and are in the same orientiation. As turnersd noted, this is done by converting the transfrags into SAM alignments and running Cufflinks on them.

The other thing that distinguishes these two options is how they deal with a reference annotation. You can read on our website how the Cufflinks Reference Annotation Based Transcript assembler (RABT) works. Cuffcompare doesn't do any RABT assembly, it just includes the reference annotation in the combined.gtf and discards partial transfrags that are contained and compatible with the reference. Cuffmerge actually runs RABT when you provide a reference, and this happens during the step where transfrags are converted into SAM alignments and assembled. We do this to improve quantification accuracy and reduce errors downstream. I should also say that Cuffmerge runs cuffcompare in order annotate the merged assembly with certain helpful features for use later on.

So we recommend #3 for a number of reasons, because it is the closest in spirit to #1 while still being reasonably fast. For reasons that I don't want to get into here (pretty arcane details about the Cufflinks assembler) I also feel that option #3 is actually the most accurate in most experimental settings.

end of quote

It's an old answer but I hope it'll help !

ADD COMMENTlink written 4.5 years ago by Thibault D.690

Thank youuu. It is very helpful and made me happy cuz I did my job in a right way. 

But I'm confused a bit. When I read the function of cuffcompare from Cufflinks manual, it seems it's job is to compare our assembled reads to known transcripts and what I understand from manual is that It is just a way to qualify our assemblies. So it should not affect our analysis workflow. Isn't it?

ADD REPLYlink written 4.5 years ago by Xin60
0
gravatar for Carlo Yague
4.5 years ago by
Carlo Yague4.9k
Canada
Carlo Yague4.9k wrote:

Here are the thought of someone that disagree with Mr Damian Kao :

" So we recommend #3[cuffmerge] for a number of reasons, because it is the closest in spirit to #1 while still being reasonably fast. For reasons that I don't want to get into here (pretty arcane details about the Cufflinks assembler) I also feel that option #3 is actually the most accurate in most experimental settings. "

ADD COMMENTlink modified 4.5 years ago • written 4.5 years ago by Carlo Yague4.9k

oops, too late ^^
 

ADD REPLYlink written 4.5 years ago by Carlo Yague4.9k

It's Ok :)

ADD REPLYlink written 4.5 years ago by Xin60
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.3.0
Traffic: 942 users visited in the last hour