New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can probably eliminate sort in RealignIndels #1137

Closed
fnothaft opened this Issue Aug 28, 2016 · 7 comments

Comments

Projects
4 participants
@fnothaft
Member

fnothaft commented Aug 28, 2016

We have a sort in the INDEL realigner that takes most of the realignment time. We do this so that we can get the full alignment position of all reads that cover a target, but this is actually an unnecessary step, since we join the reads back later and just check for overlap. If we eliminate this, we should improve INDEL realignment runtime by ~60% with negligible impact on accuracy.

I'm thinking that I'll support this via a flag.

@NeillGibson

This comment has been minimized.

Show comment
Hide comment
@NeillGibson

NeillGibson Sep 18, 2016

Contributor

GATK and Freebayes handle indel realignment inside the variant caller, eliminating the extra realign indels step.

FreeBayes documentation:

Indel realignment is accomplished internally using a read-independent method, 
and issues resulting from discordant alignments are dramatically reducedy through the direct detection of haplotypes.

GATK documentation:

Note that indel realignment is no longer necessary for variant discovery if you plan to use a variant caller that performs a haplotype assembly step, 
such as HaplotypeCaller or MuTect2. 
However it is still required when using legacy callers such as UnifiedGenotyper or the original MuTect.

If the variant caller(s) that you plan to use with Adam also are haplotype aware this would mean that you could drop the indel realignment step/tool.

Contributor

NeillGibson commented Sep 18, 2016

GATK and Freebayes handle indel realignment inside the variant caller, eliminating the extra realign indels step.

FreeBayes documentation:

Indel realignment is accomplished internally using a read-independent method, 
and issues resulting from discordant alignments are dramatically reducedy through the direct detection of haplotypes.

GATK documentation:

Note that indel realignment is no longer necessary for variant discovery if you plan to use a variant caller that performs a haplotype assembly step, 
such as HaplotypeCaller or MuTect2. 
However it is still required when using legacy callers such as UnifiedGenotyper or the original MuTect.

If the variant caller(s) that you plan to use with Adam also are haplotype aware this would mean that you could drop the indel realignment step/tool.

@iskandr

This comment has been minimized.

Show comment
Hide comment
@iskandr

iskandr Dec 12, 2016

@fnothaft Do you think your indel realigner would work with spliced RNA reads? (GATK drops those reads)

iskandr commented Dec 12, 2016

@fnothaft Do you think your indel realigner would work with spliced RNA reads? (GATK drops those reads)

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Dec 12, 2016

Member

Hi @iskandr! I believe it should, but if it doesn't, I'd be glad to help get that in. Do you have a dataset in mind that I could check on? Let me know if it'd be helpful to find a time to chat.

Member

fnothaft commented Dec 12, 2016

Hi @iskandr! I believe it should, but if it doesn't, I'd be glad to help get that in. Do you have a dataset in mind that I could check on? Let me know if it'd be helpful to find a time to chat.

@iskandr

This comment has been minimized.

Show comment
Hide comment
@iskandr

iskandr Dec 12, 2016

@ihodes ^ maybe another option for us? I'll try to take a subset of one of our B6.F10 (mouse melanoma) BAMs as example input.

iskandr commented Dec 12, 2016

@ihodes ^ maybe another option for us? I'll try to take a subset of one of our B6.F10 (mouse melanoma) BAMs as example input.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Dec 13, 2016

Member

That'd be great! I can take a look.

Member

fnothaft commented Dec 13, 2016

That'd be great! I can take a look.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft Mar 3, 2017

Member

This will be resolved after #1324.

Member

fnothaft commented Mar 3, 2017

This will be resolved after #1324.

@fnothaft

This comment has been minimized.

Show comment
Hide comment
@fnothaft

fnothaft May 12, 2017

Member

Resolved by #1324.

Member

fnothaft commented May 12, 2017

Resolved by #1324.

@fnothaft fnothaft closed this May 12, 2017

@heuermh heuermh modified the milestone: 0.23.0 Jul 22, 2017

@heuermh heuermh added this to Completed in Release 0.23.0 Jan 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment