This is a rewrite of significant portions with several goals:
1) Allow late filtering of variants (even those without assembled protein sequences) after all other computations. This allows us to preserve all information computed within Isovar, better explain why some variants are included or excluded, and use Isovar for diverse analyses (rather than just supplying the minimal amount of information used by Vaxrank).
2) Allow filtering of fragment counts, not just reads (we often end up finding two supporting reads are the same fragment in IGV)
3) Add new filtering options, such as ratio of alt to "other" (non-ref/non-alt) reads.
4) Don't use the pysam pileup engine and instead access pysam.AlignedSegment objects directly via pysam.AlignmentFile.fetch. This is both faster and eliminates some delicate error-prone logic.
5) Introduce a single IsovarResult type which contains all the information that a user could conceivably want (e.g. different read counts, fractions, best protein sequence, comparison with Varcode predicted sequence).
6) The current CLI situation is messy since many different steps of Isovar have their own commands the most useful (isovar-protein-sequences) omits potentially useful information for which you have to run other commands. This PR introduce a single command isovar which generates and saves a large DataFrame from a list of IsovarResult objects that hopefully contain all (or most) of the information a user might want. The other commands might still be useful for diagnostics (e.g. looking at protein sequences which weren't the best supported for a variant) but the CLI entry-point for Isovar will hopefully be more obvious and complete.
7) Reduce the extreme repetition of parameter lists by aggregating parameters onto objects such as ReadCollector and ProteinSequenceCreator.
8) Make the organization and location of code slightly more predictable by splitting data objects (e.g. ProteinSequence) from how they are created (ProteinSequenceCreator) and related helper functions (protein_sequence_helpers). This pattern is used across several other modules, such as variant_sequence/VariantSequenceCreator/variant_sequence_helpers, allele_read/ReadCollector/allele_ read_helpers. In the latter case the creator is called ReadCollector since it creates both AlleleRead and LocusRead objects, which rely on some intertwined logic.
This PR does not:
1) make phasing explicit: https://github.com/openvax/isovar/issues/72, though it should now be easier, just look at intersection of read names supporting protein sequences of two IsovarResult objects. Future plan: add phased_with_somatic_variants, phased_with_germline_variants to IsovarResult and fill these fields at the end of run_isovar.
Coverage increased (+1.7%) to 92.872% when pulling fbc01de6ad058c39bf2e7da6baade0c2fdc4ee44 on more-rna-filtering-options into b39b684920e3f6b344851d6598a1a1c67bce913b on master.
This is a rewrite of significant portions with several goals:
1) Allow late filtering of variants (even those without assembled protein sequences) after all other computations. This allows us to preserve all information computed within Isovar, better explain why some variants are included or excluded, and use Isovar for diverse analyses (rather than just supplying the minimal amount of information used by Vaxrank).
2) Allow filtering of fragment counts, not just reads (we often end up finding two supporting reads are the same fragment in IGV)
3) Add new filtering options, such as ratio of alt to "other" (non-ref/non-alt) reads.
4) Don't use the
pysam
pileup engine and instead accesspysam.AlignedSegment
objects directly viapysam.AlignmentFile.fetch
. This is both faster and eliminates some delicate error-prone logic.5) Introduce a single
IsovarResult
type which contains all the information that a user could conceivably want (e.g. different read counts, fractions, best protein sequence, comparison with Varcode predicted sequence).6) The current CLI situation is messy since many different steps of Isovar have their own commands the most useful (
isovar-protein-sequences
) omits potentially useful information for which you have to run other commands. This PR introduce a single commandisovar
which generates and saves a large DataFrame from a list of IsovarResult objects that hopefully contain all (or most) of the information a user might want. The other commands might still be useful for diagnostics (e.g. looking at protein sequences which weren't the best supported for a variant) but the CLI entry-point for Isovar will hopefully be more obvious and complete.7) Reduce the extreme repetition of parameter lists by aggregating parameters onto objects such as
ReadCollector
andProteinSequenceCreator
.8) Make the organization and location of code slightly more predictable by splitting data objects (e.g.
ProteinSequence
) from how they are created (ProteinSequenceCreator
) and related helper functions (protein_sequence_helpers
). This pattern is used across several other modules, such asvariant_sequence
/VariantSequenceCreator
/variant_sequence_helpers
,allele_read
/ReadCollector
/allele_ read_helpers
. In the latter case the creator is calledReadCollector
since it creates bothAlleleRead
andLocusRead
objects, which rely on some intertwined logic.Fixes:
This PR does not: 1) make phasing explicit: https://github.com/openvax/isovar/issues/72, though it should now be easier, just look at intersection of read names supporting protein sequences of two
IsovarResult
objects. Future plan: addphased_with_somatic_variants
,phased_with_germline_variants
toIsovarResult
and fill these fields at the end ofrun_isovar
.2) fix existing issues with reading missing for variants on edge of exon boundary: (https://github.com/openvax/isovar/issues/55, https://github.com/openvax/isovar/issues/14) but due to simplified logic in
ReadCreator
these should now be much easier to fix.