Corrupted index makes hisat2 run forever

[sklages]

Hi,

we created a GRCh37 index (with some extra MHC haplotype sequences included). There was no "eye-catching" error and we went on aligning or datasets with hisat2 against this index.
These jobs were running on one single cpu core (-p 12 was used) "forever".
strace was just dumping read(6, "", 4096) = 0 ... and obviously nothing happened ...
So we took a closer look at the index. There were two files missing (5+6).

• In case of an error you could make the error message more "eye-catching" during or after building the index. You could even remove the incomplete index to make people aware that there was sth. serious going wrong.
• the alignment process (or the wrapper hisat2) should probably check if the index is complete and not corrupted.

Great tool though, .. just my 2p ;-)
Sven

[infphilo]

Thanks for the detailed info!

First I need to reproduce the problem so that I can know where to put warning or error messages. How did you get those extra MHC (or HLA) sequences?

[sklages]

We are using Ensembl's GRCh37, ftp://ftp.ensembl.org/pub/grch37/release-84/fasta/homo_sapiens/dna/Homo_sapiens.GRCh37.dna.toplevel.fa.gz.
Here I extracted all main chromosomes plus HSCHR6_MHC* sequences (7x).
I ran hisat2-build with --ss and --exon. As it successfully created the index when I ran hisat2-build on a "himem machine", I assume my colleague ran out of memory on a less potent server. Nevertheless he wasn't aware of any error occuring in the build process... so it was probably not very obvious ;-)