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!
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.
I used the default option, anyways I finally found the problem, it was in the index.
Thank you!
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.
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
Log in to answer this question.
Are you using
nohup?