Notice:
If you happen to see a question you know the answer to, please do chime in and help your fellow community members. We encourage our fourm members to be more involved, jump in and help out your fellow researchers with their questions. GATK forum is a community forum and helping each other with using GATK tools and research is the cornerstone of our success as a genomics research community.We appreciate your help!

Test-drive the GATK tools and Best Practices pipelines on Terra


Check out this blog post to learn how you can get started with GATK and try out the pipelines in preconfigured workspaces (with a user-friendly interface!) without having to install anything.
Attention:
We will be out of the office on November 11th and 13th 2019, due to the U.S. holiday(Veteran's day) and due to a team event(Nov 13th). We will return to monitoring the GATK forum on November 12th and 14th respectively. Thank you for your patience.

--activeRegionIn argument nonfunctional

bolsenbolsen San FranciscoMember

I've been trying to do some manual adjustments of active regions by running HaplotypeCaller with the --justDetermineActiveRegions option, reading in and adjusting the active region output, and then rerunning HaplotypeCaller with the --activeRegionIn option.

GATK completely ignores the input ARs and produces completely identical results regardless of what active regions I provide. Inspection of the --debug output shows that the same active regions are used as originally produced.

Some source diving has shown that the input active regions are read in in the walker initialize() function, while active region identification is done in the traverser. The traverser inspects the walker to see if input regions are available, and if not, runs the standard AR identification algorithm. Unfortunately, that inspection is done only once, during the traverser initialize(), and cached for later use. In the engine execution, the traverser is initialized before the walker, and so the uninitialized walker is queried for active regions, leading to a complete drop of any input data.

Tagged:

Best Answer

Answers

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin
    Hi @bolsen, I'm afraid that sounds like a regression in the dev/debug arguments. This arg and others like it were never intended for general use, and aren't covered properly in the test suite. I believe there are some plans to overhaul some of the active region code; not sure when that will happen but when it does we'll make sure that any arguments that are exposed function correctly and are tested appropriately.
  • bolsenbolsen San FranciscoMember

    Well, if it's not going to be fixed promptly, can you at least update the documentation to make clear that it is broken so other users won't have to spend the week I did trying to get it to work?

Sign In or Register to comment.