STAR: truncated .sam

Question

[alvarocentron91]

Hello guys, I have generated a SAM file using the following line with STAR:

STAR --runThreadN 18 --genomeDir /home/acenbro/Doct2.0/Genomes/Ustilago/STAR_index --readFilesIn ../ax2_1_paired.fastq ../ax2_2_paired.fastq --sjdbGTFfile /home/acenbro/Doct2.0/Genomes/Ustilago/p3_t237631_Ust_maydi_v2GB.gtf --alignIntronMin 14 --alignIntronMax 2181 --alignMatesGapMax 10000 --limitGenomeGenerateRAM 80000000000

however, when I use SAMtools, I have the following message:

[acenbro@nodo00 STAR]$ module load SAMtools/1.3-foss-2016a
[acenbro@nodo00 STAR]$ samtools flagstat Aligned.out.sam
[E::sam_parse1] CIGAR and query sequence are of different length
[W::sam_read1] parse error at line 10548130
[bam_flagstat_core] Truncated file? Continue anyway.

So when I went to see what was the problem I found this:

 head -10548130  Aligned.out.sam | tail -1
SRR6039702.6125410      83      Um_chr01        639069  255     89M     =       639011  -147    AGAGCAACGCTCAACAAGGTCGAGCAGCAACACGCGTCG**SRR6039702.6234454**       163    Um_chr16 229194  255     89M     =       229204  99      ATCGCCAACAGCACCTGGCGGAAGCATCTCGATCAACCTCCAGCAGCCCAAAGAGCAGCTTGCACAGATCAAGCAGAACCCCCTCTCGG       HIIJJJIIIGIJJJHIJJJJJJJJJJJJJJJIJJJJHHEHFFFFFEEDDDDDDDDDDDDDDDDDDDCCDDDDDDDDDDCBDDDDDDDDD       NH:i:1  HI:i:1  AS:i:176        nM:i:0

Somehow I have a line with 2 reads and I don't know if it is ok to just eliminate those truncated reads or may I have to change my command line (don´t know how).

Thank you!

[h.mon]

Are you using nohup?

Answer 1

[ATpoint]

Looks like stdout and stderr were redirected to the same output file:

AGAGCAACGCTCAACAAGGTCGAGCAGCAACACGCGTCG**SRR6039702.6234454**

Probably STAR was throwing a warning or error to stderr here. Any warning messages during the run?

How did you save the output? That part is missing in your command.

[alvarocentron91]

I used the default option, anyways I finally found the problem, it was in the index.

Thank you!

[ATpoint]

Nice to hear that the problem is solved. Still, I kind of doubt that the index was the exact problem, because of the obvious fusion of stderr and stdout, which is unrelated to the index. In case other users ever stumble over this thread:

Given that people use nohup: As h.mon suggests above, the use of default nohup in combination with piping the STAR (or any other tool) stream to STDOUT is problematic. This is because nohup redirects stderr to stdout, so...

nohup alignment (...) | downstream-tool (...) > output &

...output will contain all the messages that were thrown to stderr, likely corrupting the file.

Better do:

nohup alignment (...) 2>>stderr.log | downstream-tool (...) 2>>stderr.log > output &

This will redirect stderr to a log file and keep stdout clean.

[alvarocentron91]

I used a sbatch queue with:

#!/bin/bash
#SBATCH -N 1
#SBATCH -n 18
#SBATCH -J star_mapping
#SBATCH -p day
#SBATCH -o star_mapping.out
#SBATCH -e ERRORstar_mapping.err
#SBATCH --constraint="SET2"
#SBATCH --mem=92gb

I got some warnings, but no problems with the mapping either in numbers or visualization in IGV