⚠ STUB — this is a goal only, not a spec. Run /spec <this issue number> before implementing.
Goal
Reconcile the SARS-CoV-2 spike pipeline's data-prep stage with the legacy analysis, and decide whether to retain in-frame codon deletions in the fitted variant set.
Finding 1 — in-frame codon deletions are dropped (original-sin defect)
experiments/scv2-spike/notebooks/prepare_data.ipynb (cell 9) filters out every variant containing a deletion:
has_deletion = df["aa_substitutions"].str.contains("-", regex=False)
df = df.loc[~has_deletion].copy()
This filter has been present since baaa0dc, the first commit of the spike pipeline — it is not a regression, it is an original-sin defect.
The legacy analysis kept them: matsengrp/SARS-CoV-2_spike_multidms@6c98b7b, data/prepped_func_scores.csv, whose first row already contains N439- and L1244-.
There is no encoding obstacle. A deletion is written <WT><site>- (e.g. P25-), structurally identical to a substitution, and every fitting entry point already builds its BinaryMap over multidms.AAS_WITHSTOP_WITHGAP, whose alphabet includes -.
Measured cost, restricted to the 6 replicates our config selects (Delta-2, Delta-4, Omicron_BA1-2, Omicron_BA1-3, Omicron_BA2-1, Omicron_BA2-2):
| Quantity |
Count |
| Unique deletion-bearing variants dropped |
8,312 (2.7% of the fittable set) |
| Unique deletion mutations lost |
881 |
| ...of those, with >=5-variant support |
354 |
| ...singletons |
215 |
| Total unique mutations currently fitted |
12,400 |
Top deletion mutations by variant support: P25- (175), N164- (123), F140- (118), T250- (113), L241- (109), H66- (104), W64- (104), I68- (103). These are NTD antigenic-supersite residues — the deletions with the most data are exactly the ones with a plausible antigenic story, which is why this is worth deciding deliberately rather than leaving as an accident.
Finding 2 — the 999,055 -> 303,007 row gap is NOT filtering
Earlier framing of this as a "3x drop from count/max_subs filters" was wrong. The exact like-for-like accounting:
legacy, all 9 replicates 999,055 barcodes
|- restricted to our 6 replicates 689,433 barcodes
|- unique (condition, aa_substitutions) 308,515 variants
|- minus WT/synonymous (6) 308,509
|- minus deletion-bearing 300,197
OURS (results-prod-294, as fitted) 303,007
Two causes, neither of them a count filter:
- Barcode -> variant aggregation. Legacy rows are barcodes; ours are aggregated variants. This is correct behavior, not a loss.
- Replicate subset. Legacy uses 9 replicates;
config.yaml selects 6.
max_subs: 10 drops only 235 legacy rows. The count thresholds are not the story.
Open question that must be answered by the spec
If deletions are restored, λ = 8.0e-05 is no longer supported by its existing evidence and must be re-derived. shift_sparsity uses stop codons as its false-positive-rate denominator, and deletions are invisible to it. Adding ~881 new β entries without changing that denominator makes the current λ justification non-transferable. See config/config_downstream.yaml lines 9-45 for the derivation that would need redoing.
Starting point
A working edit that restores deletions in prepare_data.ipynb (plus the matching evaluate.ipynb / manuscript_figures.ipynb follow-through) was parked out of PR #311 as a git stash so it would not land unreviewed:
- commit
8d911b50995e3faab4871f696f63a5bed3c73fce, tagged deletion-restoration-313 and pushed to origin
git fetch origin --tags
git show deletion-restoration-313 # view the diff
git cherry-pick -n deletion-restoration-313 # or apply it onto a fresh branch
(It began life as a git stash in the PR #311 worktree; it was tagged before that worktree was removed, so it is now durable and no longer depends on any local checkout.)
Related
Stub #312 — library mut_type() (multidms/model_collection.py:1301 and :1368) mislabels deletions as "nonsynonymous". Any deletion work must land alongside or after that fix, or the mutation-type breakdowns will be wrong.
Goal
Reconcile the SARS-CoV-2 spike pipeline's data-prep stage with the legacy analysis, and decide whether to retain in-frame codon deletions in the fitted variant set.
Finding 1 — in-frame codon deletions are dropped (original-sin defect)
experiments/scv2-spike/notebooks/prepare_data.ipynb(cell 9) filters out every variant containing a deletion:This filter has been present since
baaa0dc, the first commit of the spike pipeline — it is not a regression, it is an original-sin defect.The legacy analysis kept them:
matsengrp/SARS-CoV-2_spike_multidms@6c98b7b,data/prepped_func_scores.csv, whose first row already containsN439-andL1244-.There is no encoding obstacle. A deletion is written
<WT><site>-(e.g.P25-), structurally identical to a substitution, and every fitting entry point already builds itsBinaryMapovermultidms.AAS_WITHSTOP_WITHGAP, whose alphabet includes-.Measured cost, restricted to the 6 replicates our config selects (
Delta-2, Delta-4, Omicron_BA1-2, Omicron_BA1-3, Omicron_BA2-1, Omicron_BA2-2):Top deletion mutations by variant support:
P25-(175),N164-(123),F140-(118),T250-(113),L241-(109),H66-(104),W64-(104),I68-(103). These are NTD antigenic-supersite residues — the deletions with the most data are exactly the ones with a plausible antigenic story, which is why this is worth deciding deliberately rather than leaving as an accident.Finding 2 — the 999,055 -> 303,007 row gap is NOT filtering
Earlier framing of this as a "3x drop from count/max_subs filters" was wrong. The exact like-for-like accounting:
Two causes, neither of them a count filter:
config.yamlselects 6.max_subs: 10drops only 235 legacy rows. The count thresholds are not the story.Open question that must be answered by the spec
If deletions are restored, λ = 8.0e-05 is no longer supported by its existing evidence and must be re-derived.
shift_sparsityuses stop codons as its false-positive-rate denominator, and deletions are invisible to it. Adding ~881 new β entries without changing that denominator makes the current λ justification non-transferable. Seeconfig/config_downstream.yamllines 9-45 for the derivation that would need redoing.Starting point
A working edit that restores deletions in
prepare_data.ipynb(plus the matchingevaluate.ipynb/manuscript_figures.ipynbfollow-through) was parked out of PR #311 as a git stash so it would not land unreviewed:8d911b50995e3faab4871f696f63a5bed3c73fce, taggeddeletion-restoration-313and pushed toorigin(It began life as a git stash in the PR #311 worktree; it was tagged before that worktree was removed, so it is now durable and no longer depends on any local checkout.)
Related
Stub #312 — library
mut_type()(multidms/model_collection.py:1301and:1368) mislabels deletions as "nonsynonymous". Any deletion work must land alongside or after that fix, or the mutation-type breakdowns will be wrong.