Incorrect Mutation Position value

[arosenfeld]

Installation Type

Docker

pVACtools Version / Docker Image

griffithlab/pvactools:4.0.5

Python Version

No response

Operating System

No response

Describe the bug

In some all_epitopes.tsv, the location of a mutation is incorrectly calculated for the "Mutation Position" column. For example in the attached file:

MT Epitope Seq: VAEGGRNTL
WT Epitope Seq: VAEGGPNTL
Mutation Position: 0

The mutation position should actually be 6 where P -> R.

How to reproduce this bug

The pvacseq command we ran was:

pvacseq run \
    tumor.vcf.gz \
    TUMOR \
    'HLA-A*23:01,HLA-A*32:01,HLA-B*14:01,HLA-B*44:03,HLA-C*04:01,HLA-C*08:02' \
    MHCflurry \
    out \
    --normal-sample-name NORMAL \
    --iedb-install-directory /opt/iedb \
    --run-reference-proteome-similarity \
    --peptide-fasta /Homo_sapiens.GRCh38.pep.all.fa.gz \
    -t 32 \
    -p \
    vep_phased.vcf.gz

Input files

No response

Log output

None

Output files

BUG.all_epitopes.tsv.gz

[susannasiebert]

Thank you for this bug report. #1191 reported the same issue and I'm actively working on a fix. My best guess for your case is that there is a proximal somatic variant and it's incorrectly tracking the mutation position of that variant. Would you be able to share an input VCF with just the one main somatic variant with us as well as the proximal VCF (either the full proximal VCF or one scoped to an appropriate region around the somatic variant) so that I can test my fix to ensure it also resolves your issue?

[susannasiebert]

This issue has been resolved in the newest release (5.2.0). Please note that the Mutation Position/Pos column now has a slightly different meaning than before. From the release notes:

• The meaning of the Mutation Position column (in the all_epitopes.tsv and filtered.tsv pVACseq reports) and the Pos column (in the aggregated pVACseq report) has been updated to reflect the position(s) in the mutant epitope that are different from the matched wildtype epitope.
  • This is different from the previous behaviors, particular for indels, where previously this column was trying to reflect where the mutation occurred. However, this has proven difficult to programmatically determine correctly for cases with proximal variants, in repetitive regions, or where the mutant amino acid(s) are similar the wildtype amino acid(s).
  • For inframe indels, this change might now result in some positions getting marked as different from the matched wildtype amino acid even though they aren’t technically part of the variant because wildtype amino acids are shifted in relation to the mutant in this type of variants. These shifted amino acids, although not mutated, are now different between mutant and matched wildtype epitope and marked as such. We do believe that this is the better approach because it allows us to evaluate the absolute differences between the matched wildtype and mutant epitopes.
  • These columns are now always NA if the wildtype epitope is NA
  • For making the anchor position evaluation, epitopes with more than two Mutation Position/Pos entries are auto-passed.