Cufflinks error

[brachysclereid]

When running cufflinks I get the following error:

$ cufflinks -G annotation.gtf ./s_1/accepted_hits.bam
cufflinks: /usr/lib64/libz.so.1: no version information available (required by cufflinks)
Error: sort order of reads in BAMs must be the same

I am using TopHat v1.1.4 to create the BAMs with bowtie indexes.
The cufflinks version is cufflinks v0.9.3.

Based on previous posts I tried reverting from the BAM to SAM, but got the same result.

Any ideas? Thanks!

[jgarbe]

I've run into the same issue...

[ameyer]

I've had this error as well. I emailed the help email address and they said it's a rare issue with the software where the contig names have hash collisions. The problem should be fixed when they release Cufflinks v1.0.

[brachysclereid]

Thanks for the information. Did they mention when they would release that version?

[Aurelien Mazurie]

I had exactly the same problem; sorting the BAM file didn't help.

[ameyer]

Tech support was able to find the cause of my error in my SAM file. In the header section I had some colons as part of my contig names that messed up Cufflinks. By removing the colons in the header and throughout the file I stopped getting this error.
Originally I had:
@SQ SN:chromosome:AGPv2:1:1:301354135:1 LN:301354135
and this changed to:
@SQ SN:chromosome1 LN:301354135

Hope this helps.

[Aurelien Mazurie]

Interesting. I checked my SAM files, and the @SQ lines only have two colons:

@HD VN:1.0 SO:sorted
@SQ SN:EG:bd_7x3 LN:450
@SQ SN:EG:bd_6x3 LN:450
@SQ SN:EG:bd_36x35 LN:554
@SQ SN:EG:bd_55x36 LN:808
@SQ SN:EG:bd_54x36 LN:1351
@SQ SN:EG:bd_16x14 LN:1992
@SQ SN:EG:bd_53x36 LN:2027
@SQ SN:EG:bd_52x36 LN:2040
@SQ SN:EG:bd_51x36 LN:2113
@SQ SN:EG:bd_37x35 LN:2489
. . .

From your experience, is that enough to trigger the error?

What about the reads references after that? Mine do contain a lot of colons. Did you have to modify them to? E.g.,

@PG ID:TopHat VN:1.2.0 CL:../Applications/tophat/1.2.0/tophat -o ./2_run_TopHat/JV-
A_on_Phatr-ENSEMBL-unmasked --num-threads 4 -G ../Data/Genome/ENSEMBL/Phaeodactylum_tricornutum.Phat
r2.61.gtf ./1_create_Bowtie_index/Phatr-ENSEMBL-unmasked ../Data/Expression/2011.02.02/JV-A.fastq
SNPSTER7_0744:2:33:16520:18860#0 16 EG:bd_6x3 5 255 54M * 0 0 TGGAAATCTAAAGTTCACGATACACCAATCATTCAGTCTGAGGTTGATACTTTC hhhhhhehhhhhhfffdaedfdfbhfhhg
hhfhhhhhhfhhghghhhhhfffff NM:i:0 NH:i:1
SNPSTER7_0744:2:58:18789:10460#0 16 EG:bd_6x3 6 255 54M * 0 0 GGAAATCTAAAGTTCACGATACACCAATCATTCAGTCTGAGGTTGATACTTTCG [ffffc_ccfffWcZ\Z\ZYT_NYcfaaf
ffcfccff]fffccffffafffafc NM:i:0 NH:i:1
. . .

[ameyer]

The only colons that are allowed in the @SQ lines are the ones directly after SN and LN so the one you have between EG and bd would have to be removed. It would also have to be removed in all the read references so that the the names match each other.
So for example you would have:
@SQ SN:bd_6x3 LN:450
and:
SNPSTER7_0744:2:33:16520:18860#0 16 bd_6x3 5 255 54M * 0 0 TGGAAATCTAAAGTTCACGATACACCAATCATTCAGTCTGAGGTTGATACTTTC hhhhhhehhhhhhfffdaedfdfbhfhhg
hhfhhhhhhfhhghghhhhhfffff NM:i:0 NH:i:1

[Aurelien Mazurie]

It works, thanks! For those interested I wrote a Python script to do the job, which is enclosed.

Aurelien

[delphi_ote]

Originally Posted by Aurelien Mazurie

It works, thanks! For those interested I wrote a Python script to do the job, which is enclosed.

Aurelien

Your script just saved my bacon. Thank you SO much for this!!!

[eieneg]

COLONS in the fasta and GFF!!!!!