Consider changing htseq_count's default sort option setting to Yes (currently is No and users are confused)

[jennaj]

Tool: htseq-count - Count aligned reads in a BAM file that overlap features in a GFF file (Galaxy Version 0.6.1galaxy3)

Even though the tool help explains that the option Force sorting of SAM/BAM file by NAME should be set to Yes for paired-end data that fails, users are having trouble understanding this is needed/the solution and are reporting questions about the failed jobs nearly daily when working at https://usegalaxy.org. The default is currently set to "No".

I noticed that at https://galaxy.uni-freiburg.de the setting has the default as "Yes" (also Galaxy Version 0.6.1galaxy3). Maybe we should do the same? @nekrut @jxtx @natefoo What do you think?

Example Q&A: https://biostar.usegalaxy.org/p/26085/, also see galaxy-bugs list if internal - most reports for this tool are about this use case. Be great to eliminate it as a routinely reported "bug".

The error ends like this. It is sometimes proceeded by GFF format/content warnings that can usually be ignored.

Fatal error: Unknown error occured
81732 GFF lines processed.
100000 SAM alignment record pairs processed.
Error occured when processing SAM input (record #3340229 in file /galaxy-repl/main/files/XXX/XXX/dataset_XXXX.dat):
  Maximum alignment buffer size exceeded while pairing SAM alignments.
  [Exception type: ValueError, raised in __init__.py:671]

The tool form option has this content, which doesn't seem to be enough info or a close enough language match to the error message to be interpreted/acted upon by many users without more help.

[natefoo]

I am unsure how this option defaults to True on usegalaxy.eu since in the tool xml it defaults to False - any idea @erasche?

Anyway, there is a new version, 0.9.1, and this option has been removed from it, so we should probably just upgrade (usegalaxy.eu has this new version installed).

[hexylena]

I'd guess edited on disk to deal with similar error reports. @bgruening?

[natefoo]

Thanks @erasche.

@jennaj we can go back and edit to change the default, but @davebx has also just upgraded to 0.9.1, so I would suspect the issue won't come up going forward.

[bgruening]

Sorry for being late to the game here. Back at the time I discussed this with the upstream tool author (:wave: @lparsons :)) and he did not want to change the default. Because we were swamped with bug-reports I was forced to either fork this tool or change it internally :( I don't consider forking good ... but maybe this was a bad decision.
However, things have changed and Lance contributed this tool to IUC, so we can do this now ... Lance?

[lparsons]

@bgruening I am pretty sure @natefoo is correct, and the new version already defaults to sorting (and thus will not exhibit this behavior).

[jennaj]

Agree - it sorts by default and works for most cases. I'm retesting the problem functionality I found earlier - may have been a data problem. Will open a ticket against the dev repo if I find anything.

Thanks so much for the update! The bugs sent in related to paired-end inputs/sort/exceeding mem have completely gone away. Win!