Check -s and -l if out of bounds happen. about htstream

[msettles]

bumping, Davis is this fixed and can be closed?

[msettles]

Bumping again

[msettles]

So this must be super-deduper as its the only app that makes sense with both an s an l parameter. Near as I can tell this is still and issue, when start and length are out of range

[samhunter]

As David noted, it looks like hts_SuperDeduper does ignore (discard) reads for which the --start and --length (-s and -l) create a window outside of the read. I think this is expected behavior, or at least I can't imagine an alternative behavior that would be more appropriate.

Tests:

1. when -s is set to a position outside the length of the reads, all reads are ignored
2. when -s is set of a position inside the length of the reads, but too close to the end for a pattern to be obtained (read_length < s + l) all reads are ignored
3. when -s is set as a negative value, an error is returned
4. when -l is set to 0 an error is returned

My hope is that the default settings we have for -s and -l (based on pretty in-depth testing done previously in Petersen, K. R., Streett, D. A., Gerritsen, A. T., Hunter, S. S., & Settles, M. L. (2015, September). Super deduper, fast PCR duplicate detection in fastq files. In Proceedings of the 6th ACM Conference on Bioinformatics, Computational Biology and Health Informatics (pp. 491-492). ACM.) will be left alone. There are only a few reasons I can see for changing these settings: a) read quality is poor in this region due to sequencer issues etc, b) base call failure in this region due to sequencer "hickup"

I am closing this issue since it I think behavior is as expected.

@dstreett please comment if I've totally missed the point.