Is your feature request related to a problem? Please describe.
This request concerns how iVar handles the minimum frequency threshold for consensus calling via the -t parameter. As discussed in Issue #51, the current behavior can be unintuitive and offers limited control over how bases are incorporated into the consensus sequence.
Specifically, there is no way to require that a base be supported by a minimum fraction of reads before being included in the consensus. Additionally, there is no option to ensure that the resulting consensus sequence contains no mixed IUPAC ambiguity codes.
Describe the solution you'd like
I am requesting a new option that allows users to explicitly define the minimum fraction of reads required to make a consensus base call.
Describe alternatives you've considered
Currently, there is no direct alternative within iVar. The only workaround is manual inspection and post-processing of mixed sites after consensus generation, which is inefficient and not scalable for larger workflows.
Is your feature request related to a problem? Please describe.
This request concerns how iVar handles the minimum frequency threshold for consensus calling via the
-tparameter. As discussed in Issue #51, the current behavior can be unintuitive and offers limited control over how bases are incorporated into the consensus sequence.Specifically, there is no way to require that a base be supported by a minimum fraction of reads before being included in the consensus. Additionally, there is no option to ensure that the resulting consensus sequence contains no mixed IUPAC ambiguity codes.
Describe the solution you'd like
I am requesting a new option that allows users to explicitly define the minimum fraction of reads required to make a consensus base call.
Describe alternatives you've considered
Currently, there is no direct alternative within iVar. The only workaround is manual inspection and post-processing of mixed sites after consensus generation, which is inefficient and not scalable for larger workflows.