Tweet
Hi there,
I hope this is the correct forum to ask this question. I'm getting some weird/inconsistent results when using the latest version of cufflinks and wonder if anyone else is getting the same thing or can tell me if I'm doing something wrong. I guess firstly I should state that I'm using the latest versions of the tools in the chain (Bowtie 2.0.0.6, Tophat v2.0.1, cufflinks v2.0.0). Basically I've noticed two different strange behaviours:
1) I accidentally ran cufflinks with the wrong .gtf file where instead of having "Chr1","Chr2",... it had "1","2",.... The strange thing was that in the "genes.fpkm_tracking" file it still had fpkm's for the genes in the .gtf. If I compare these against when I run it with the correct .gtf I get different values. The thing that concerns me is that it's assigning read counts where it shouldn't and this possibly indicates that a variable isn't being initialised properly?
2) Now I'm running it on the correct .gtf file I find that the output file is a little bit inconsistent -- specifically if I look at columns 5 and 6 (gene_short_name and tss_id), I find that for some runs it fills this value in, and for some doesn't. For instance using the commands:
"cufflinks -q -u --upper-quartile-norm -p 6 -o 12036_TTAGGC/cufflinks_4 -g reference/genes.edited.2.gtf -b reference/TAIR10.edited.fa 12036_TTAGGC/tophat_4/accepted_hits.bam "
and
"cufflinks -q -u -p 2 -o 12036_TTAGGC/cufflinks_5 -g reference/genes.edited.2.gtf -b reference/TAIR10.edited.fa 12036_TTAGGC/tophat_4/accepted_hits.bam"
(note the only difference is one uses "--upper-quartile-norm" and they use different number of processors)
gives one file with filled in "gene_short_name"s and "tss_id"s and one without. This behaviour doesn't even seem to be consistent -- so if I'm running with -p 6 and --upper-quartile-norm, but on different samples, then sometimes the output has those values and sometimes it doesn't (despite using the same .gtf and the same .fa files).
I've got more than enough ram (96GB) and disk space (2+TB). One thing that did occur to me is that maybe it's using temporary files and since I'm running things in parallel (testing different parameters) maybe it's getting corrupted somehow?
Any idea what might be going on?
Thanks for your help and suggestions,
Dane Kennedy.
I hope this is the correct forum to ask this question. I'm getting some weird/inconsistent results when using the latest version of cufflinks and wonder if anyone else is getting the same thing or can tell me if I'm doing something wrong. I guess firstly I should state that I'm using the latest versions of the tools in the chain (Bowtie 2.0.0.6, Tophat v2.0.1, cufflinks v2.0.0). Basically I've noticed two different strange behaviours:
1) I accidentally ran cufflinks with the wrong .gtf file where instead of having "Chr1","Chr2",... it had "1","2",.... The strange thing was that in the "genes.fpkm_tracking" file it still had fpkm's for the genes in the .gtf. If I compare these against when I run it with the correct .gtf I get different values. The thing that concerns me is that it's assigning read counts where it shouldn't and this possibly indicates that a variable isn't being initialised properly?
2) Now I'm running it on the correct .gtf file I find that the output file is a little bit inconsistent -- specifically if I look at columns 5 and 6 (gene_short_name and tss_id), I find that for some runs it fills this value in, and for some doesn't. For instance using the commands:
"cufflinks -q -u --upper-quartile-norm -p 6 -o 12036_TTAGGC/cufflinks_4 -g reference/genes.edited.2.gtf -b reference/TAIR10.edited.fa 12036_TTAGGC/tophat_4/accepted_hits.bam "
and
"cufflinks -q -u -p 2 -o 12036_TTAGGC/cufflinks_5 -g reference/genes.edited.2.gtf -b reference/TAIR10.edited.fa 12036_TTAGGC/tophat_4/accepted_hits.bam"
(note the only difference is one uses "--upper-quartile-norm" and they use different number of processors)
gives one file with filled in "gene_short_name"s and "tss_id"s and one without. This behaviour doesn't even seem to be consistent -- so if I'm running with -p 6 and --upper-quartile-norm, but on different samples, then sometimes the output has those values and sometimes it doesn't (despite using the same .gtf and the same .fa files).
I've got more than enough ram (96GB) and disk space (2+TB). One thing that did occur to me is that maybe it's using temporary files and since I'm running things in parallel (testing different parameters) maybe it's getting corrupted somehow?
Any idea what might be going on?
Thanks for your help and suggestions,
Dane Kennedy.