I have been trying for many times to use HISAT2 to align trimmed reads from bulkRNAseq fastq files. 7 out of 9 samples worked fine, but this last 2 paired reads samples are keep getting stuck and the error says: not enough memory allocated for this job.
I reported all these errors with the bug symbol, but still I am getting the same errors over and over.
How to deal with this?
thanks
Update:
We were able to dig into the logs. It does look like the problem is with the reads. You’ll need to correct this before mapping.
If you run FastQC, it would also report about this (even though it is checking content), and Fastq Info is dedicated for technical issues or ensuring intact pairs.
So, a partial Galaxy Upload from the start, or the file is truncated at the source before Upload to Galaxy (maybe from an upstream data transfer).
Hope this helps!
(ERR): hisat2-align died with signal 9 (KILL)
[E::sam_parse1] SEQ and QUAL are of different length
[W::sam_read1_sam] Parse error at line 37133518
samtools sort: truncated file. Aborting
[main_samview] fail to read the header from "-".
I think that I found your bug reports sent into UseGalaxy.org.
If those are yours: The pairs are not very large, and appeared to have gone through QA. So that leaves scientific reasons (read content versus the parameters and reference genome) or potential server issues. The mm10 index seems fine on the server, but there was a small cluster issue for a few hours today.
Please try this:
That said, if the rerun does produce another error, would you please send in another bug report from one of those? If you could include a link to this topic in the comments that will help me to associate everything together. I’d like to get you a solution since this mapping should definitely work if the reads are actually from mouse, and have decent quality scores.
FWIW: this is the FAQ for the error type for anyone else reading FAQ: Understanding 'exceeds memory allocation' error messages
still have the same issue.
Yes, I’ve seen your bug reports. Those reads do not want to map. Have you addressed the sequence quality yet? Did I miss it?
I reloaded the fastq files, I retrimmed them, I did QC after the trimming and iit shows adapter gone. Overall the quality is good so really I dont get it. I got 20 times the error regarding memory allocation. I really would like to move this forward. I also tried to useRNASTAR and it gave me mapped bam. the only problem is that once I use stringtie to quantify te reads, Stringtie doesnt like the bam file from RNA STAR as much s the one from HISAT, so even though I followed the exact indication underneath RNASTAR mapping to add xs and other edits in thhe BAM output files, they still did not worked when I tried to get the output for DESeq2.
I agree that this is strange. Maybe try a different mapping tool to explore what is going on with those reads? You could also look at the other FastQC sections (post trimming) for clues. How to interpret those is linked at the bottom of the tool form – in particular, see the link to the author site since they have examples of “good vs bad” data.
We can’t make an underlying tool accept data, and this tool already has sufficient resources for the vast majority of work. It will process fastq data that is nearly an order of magnitude large than your problem sample – so it is the read content that is the factor to address, not the size of the file. I’m guessing this would fail even outside of Galaxy from what I’ve seen so far.
One suggestion: The UseGalaxy.eu server can sometimes allocate more memory and a longer runtime to tools, so you could try a cross-check there 
you might get at least a better log message.