Hey,
I have an error from HISAT2. Some of the samples are errors and others have this:
Auto-detect is actually heplful. HISAT2 runs again on my sample and the second times it works. One question: Why and how? It affects my results in any way?
It says “This will inspect the dataset and attempt to correct the values of fields if they are not accurate”. However, I am not sure how it works.
Thanks.
This was probably a small server glitch with setting the metadata. Re-detecting metadata can help (pencil icon > Edit attributes > Datatype).
Hard to say. You might try rerunning a few and compare. Assuming that you already checked your inputs (did QA on the reads before mapping).
This sometimes happens when the BAM output has header lines but no data lines (hits), so the output cannot be sorted. There are many Samtools and Picard tools that can generate BAM stats and other summaries. Or, just look at the file (eye icon) and confirm there are hits.
I will come back to this topic with some new informations. So I ran once more the failed samples with autodetect which solved the problem and I rerun the same samples again in HISAT2. This time just one out of five samples requred another auto-detect. The other four ran just fine from the first try this time.
However, I took a glance at them in IGV on a ~20kb region and I identified a tiny difference in each in the coverage track:
The upper coverage track is the one that went through an extra step of auto-detect (as specified in the question above). The other one is the sample that I rerun in HISAT2 and it worked just fine.
Sorry for the pictures not being aligned. I hope it makes sense for you as well. I still can’t fully explain what is this failure about.
The zoom scaling looks a bit off, so is not a direct comparison or I am missing something…
Mappers are dynamic. Meaning, you will not always get the same exact results each run, in Galaxy or line-command.
Thank you. This is actually helpful information. I ran a sample on HISAT2 and Bowtie2 and the differences (besides the splices) were quite rare. More like this (which is understandable because HISAT2 uses Bowtie2 algorithm to some extend.
No, the scale is not off. There are 2 sets of images. And they are paired vertically. Sorry, there are not the best of pictures 
Just as a note,
I’ve been getting the same error with HISAT2, I don’t know why but it happens to my bam files randomly when they are in a queue to be processed further downstream.
For example : I had HISAT2 running, and then set up a FeatureCount to take place on the generated bam file (that was currently processing).
Usually (i.e a year ago), when the bam file was ready, featurecounts would kick off as expected - but lately whenever I set up files as a queue I get this error occurring in the bam files.Which then prevents the queued counts job from running causing it to turn red.
Hope this adds more information to maybe squish an undetected bug.
