Multiple entries in remap.fq*.gz for single read pair about wasp HOT 9 CLOSED

Looking at my older runs of WASP, it seems that reads were output multiple times in the fastq files in the past as well. I guess the bug here may be that this read pair doesn't make it through the filtering step even though it aligns to the same spot. I've added files to the zip that show this.

from wasp.

Hi Chris, thanks for the bug report, looking into this now...

from wasp.

I think I found the problem and have committed a fix here:
b1e8219

Thanks again for the bug report and let us know if you have any further issues.

from wasp.

Thanks Graham. It seems the results (e.g. whether a read pair is kept or not) from the mapping pipeline weren't affected by this bug right?

from wasp.

I am not 100% certain, but unfortunately I think that it could have
affected which paired end reads are filtered. I think that some PE reads
may have dropped out of the pipeline even though they could have been kept.

The other outstanding issue is that Step #5 (rmdup) does not currently
support PE reads. I am working to fix this now.

On Thu, Jun 25, 2015 at 12:50 PM, Christopher DeBoever <
[email protected]> wrote:

Thanks Graham. It seems the results (e.g. whether a read pair is kept or
not) from the mapping pipeline weren't affected by this bug right?

—
Reply to this email directly or view it on GitHub
#18 (comment).

from wasp.

It turns out the 'fix' I made was not correct and has created some issues with the PE reads. I have reverted to the old version and I am working on fixing the original issue (which was minor by comparison).

from wasp.

Sounds good, I was actually looking at the code last week although so far
I've mostly just added comments. I'm hoping to start refactoring a bit
tomorrow and adding in some unit tests.

On Mon, Jul 27, 2015 at 2:39 PM, Graham McVicker [email protected]
wrote:

It turns out the 'fix' I made was not correct and has created some issues
with the PE reads. I have reverted to the old version and I am working on
fixing the original issue (which was minor by comparison).

—
Reply to this email directly or view it on GitHub
#18 (comment).

from wasp.

I've been able to clean up the code a bit and add a lot of documentation and some tests (0170a01). I actually looked into this bug and it turns out it's not a bug. The two reads both overlap the SNP so the three possible read pairs are output. I added a test for the data I provided initially.

I can make a pull request, but I was also wondering if we could add an option to specify that the input bam file is already coordinate sorted? I can add that in before I make the pull request.

from wasp.

Hi Chris,

That changes and test look great. You are welcome to add an option to
indicate that the input bam is already sorted. Once you are ready to make a
pull request we can accept it.

Thanks a lot for your help!

Graham

On Mon, Aug 3, 2015 at 3:17 PM, Christopher DeBoever <
[email protected]> wrote:

I've been able to clean up the code a bit and add a lot of documentation
and some tests (0170a01
0170a01).
I actually looked into this bug and it turns out it's not a bug. The two
reads both overlap the SNP so the three possible read pairs are output. I
added a test for the data I provided initially.

I can make a pull request, but I was also wondering if we could add an
option to specify that the input bam file is already coordinate sorted? I
can add that in before I make the pull request.

—
Reply to this email directly or view it on GitHub
#18 (comment).

from wasp.