Cufflinks "randomly" dropping fpkms -- how to replace?

[arielpaulson]

Hi,

I would have thought that someone else had noticed this by now, but I have not been able to find this issue addressed elsewhere in this site...

Cufflinks seems to randomly drop FPKM values. For instance, my current dataset has 6 mouse RNAseq samples quantitated using tophat 1.4.0 / cufflinks 1.3.0, -G, Ensembl 63 gtf, no multireads. On average, 19% of the zero-fpkm genes in any sample will have a nonzero read count.

I quantify read counts using intersectBed to return read tallies on the nonredundant exonic space per gene, and verify presence of reads in the track files. So I can have genes with tens, even hundreds of thousands of reads, but zero fpkms.

Some genes are consistently high-count and zero-fpkm in all samples; others have fpkms in some samples but not others (while the RPMs are ~consistent across samples). The majority of affected genes are only dropped in a few samples, suggesting this is not a gene structure or annotation issue. In particular, the fairly consistent fraction of dropped fpkms per sample makes me wonder if it has something to do with the read-to-locus assigment algorithms.

I first noticed this effect in January of last year but brushed it off and assumed it would be fixed later on, but this hasn't been the case. This issue has appeared in three unrelated investigations since then (all mouse -- but I doubt that's the underlying issue ).

So to make a long story short, has anyone else noticed this, and if so what measures do you take to fill in lost FPKMs? Or do you just work with the counts instead?

Thanks,
Ariel

[Cole Trapnell]

Ariel,

Can you send (to the cufflinks support list) us a small test set of data and a GTF that reproduces this problem? I suspect (as you do) that it has to do with differences in how bedTools and Cufflinks/Cuffdiff handle fragment to isoform assignment. We have a number of sanity filters in the BAM and GTF parsers that could also be at work here.

[peromhc]

Any progress on this? I have a similar problem, where Cufflinks drops a transcript (no entry in transcripts.gtf) when there are plenty of reads mapping to that transcript when manually examining the SAM/BAM.. Im not using a reference GTF file

Ideally, Cufflinks would report all transcripts, even those truly with 0 FPKM.

[lzlgboy]

I also notice that, some genes have many reads (see in IGV with bam) but the FPKM value are 0. I have try cufflinks 1.3.0 cufflinks 2.0.0, the result for that gene is the same. I don't know whether we can still trust cufflinks.

[kopi-o]

It seems there are two different issues being discussed here:

1) FPKM=0 in the output file(s) even though reads are mapping to the region in question;
2) no entry for the relevant gene/transcript in the output file(s) at all.

I am having problems with 2) (using Cufflinks 1.3.0) and it annoys me a lot.

[EricHaugen]

Also experiencing
> 2) no entry for the relevant gene/transcript in the output file(s) at all.
using cufflinks-2.0.2.Linux_x86_64 with Ensembl 65 mouse annotations.

The same transcripts are dropped if a BAM file from another sample is used.

If I re-run cufflinks with the same parameters except a smaller GTF containing some of the missing transcripts, it includes them successfully.