STAR v.2.5.1b is producing Chimeric.out.junction with no spanning fragments

[Peter Waltman]

This issue popped up while using STAR as part of STAR-Fusion. The data I'm working with was sequenced using paired end reads that are 151bp long.  After some investigating, I discovered that the Chimeric.out.junction file that is being produced by STAR has exactly 0 reads that have -1 in the 7th column. 

As a result, this is causing STAR-Fusion to report 0 SpanningFrags for all the fusions it identifies. I have also made a post on the STAR-Fusion user group as well (https://groups.google.com/forum/#!topic/star-fusion/F3alUe-q6rs). For what it's worth, since my sequencing data is paired end, with 151pb reads; I built the STAR-Fusion resource directory using the --sjdbOverhang set to 150, as I discussed in a previous forum post on the STAR-Fusion group.

[Alexander Dobin]

Hi Peter,

I have checked my runs, and I can see plenty of reads with -1 in column 7 of Chimeric.out.junction.

These are alignments with mates mapping discordantly (chimerically).

Could you please send me you Log.out file, and also ~10,000 lines of the Chimeric.junction.out file?

Cheers

Alex

[Peter Waltman]

Hi Alex -

Sorry for the delay, but I didn't get an email warning me you had replied.  Here are the requested files. Note, these were built as part of the STAR-Fusion pipeline, using a resource directory that was built, using a copy of the human reference from gencode (rel. 19; GRCh37.p13.genome.fa). I'm currently re-running STAR-Fusion using the reference that is part of the STAR-Fusion resource bundle (although I don't think that that should make much difference)

Thanks!

Peter

[Alexander Dobin]

Hi Peter,

I think you are missing the 2nd read fastq in your run - or do you have single-end data?

For single-end reads you cannot have any chimeric pairs (-1 in col 7 of Chimeric.out.junction), which - by definition - require 2 ends.

Cheers

Alex

[Peter Waltman]

Yep, that's it. The data is paired end, but there was a bug in the wrapper script that I was/am using that was causing only the left reads to be passed in correctly...  friggin' stupid error with echo.  I had all the relevant info in a tab-delimited file that I echo'd to cut, but by not using the -e param, the tabs were being stripped out, i.e. the difference between

fq1=$( echo $line |cut -f2 )  

versus

fq1=$( echo -e "$line" |cut -f2 )

Thanks, and sorry for the trouble!

[Alexander Dobin]

Hi Peter,

great, thanks for sorting it out and letting me know. The simple bugs are often the hardest to find... :)

Cheers

Alex