Summary
--soloUMIfiltering MultiGeneUMI_All currently resolves to the same behaviour as MultiGeneUMI:
// src/solo/count.rs:124-125
// MultiGeneUMI_All behaves like MultiGeneUMI for the count matrix.
"MultiGeneUMI" | "MultiGeneUMI_All" => Ok(Self::MultiGeneUmi),
(same alias documented at src/params/mod.rs:1090).
That is neither what STAR 2.7.11b does nor what the option is documented to do, so rustar is currently the only one of the three behaviours that nobody asked for.
What STAR 2.7.11b actually does
In STAR, MultiGeneUMI_All is a no-op. The option is parsed and stored, but the consumption site tests only the MultiGeneUMI flag, so selecting MultiGeneUMI_All alone leaves the multi-gene UMI filter entirely disabled. The counts you get are the unfiltered counts.
What it is documented to do
STAR's documentation describes the two as:
MultiGeneUMI: remove the lower-count gene's reads when a UMI is assigned to more than one gene.
MultiGeneUMI_All: when a UMI is assigned to more than one gene, remove it from all of those genes, not just the losers.
So MultiGeneUMI_All is strictly more aggressive than MultiGeneUMI. Aliasing it to MultiGeneUMI silently under-filters; STAR's own no-op silently does not filter at all.
Three options
- Reproduce STAR's no-op. Maximum byte-fidelity: a run with
--soloUMIfiltering MultiGeneUMI_All matches STAR exactly. Also means the flag does nothing, which will surprise anyone who reads the STAR docs.
- Implement the documented behaviour (split the enum variant, drop cross-gene UMIs from every gene they touch). Diverges from STAR on this one flag, with a documented entry and a locking test.
- Status quo (alias to
MultiGeneUMI). Matches neither.
Resolution
Option 2, implemented in #152:
- a separate
UmiFiltering::MultiGeneUmiAll variant rather than an alias;
- an entry in a new
docs-old/dev/divergences.md recording the deviation and the reason;
test_solo_multigene_umi_all_drops_cross_gene_umis asserting the correct result, never STAR's no-op.
Only the MultiGeneUMI_All path changes; the default (-) and the other modes produce identical output. If option 1 is preferred instead, the test asserts the behaviour either way and inverting it is a one-line change.
Summary
--soloUMIfiltering MultiGeneUMI_Allcurrently resolves to the same behaviour asMultiGeneUMI:(same alias documented at
src/params/mod.rs:1090).That is neither what STAR 2.7.11b does nor what the option is documented to do, so rustar is currently the only one of the three behaviours that nobody asked for.
What STAR 2.7.11b actually does
In STAR,
MultiGeneUMI_Allis a no-op. The option is parsed and stored, but the consumption site tests only theMultiGeneUMIflag, so selectingMultiGeneUMI_Allalone leaves the multi-gene UMI filter entirely disabled. The counts you get are the unfiltered counts.What it is documented to do
STAR's documentation describes the two as:
MultiGeneUMI: remove the lower-count gene's reads when a UMI is assigned to more than one gene.MultiGeneUMI_All: when a UMI is assigned to more than one gene, remove it from all of those genes, not just the losers.So
MultiGeneUMI_Allis strictly more aggressive thanMultiGeneUMI. Aliasing it toMultiGeneUMIsilently under-filters; STAR's own no-op silently does not filter at all.Three options
--soloUMIfiltering MultiGeneUMI_Allmatches STAR exactly. Also means the flag does nothing, which will surprise anyone who reads the STAR docs.MultiGeneUMI). Matches neither.Resolution
Option 2, implemented in #152:
UmiFiltering::MultiGeneUmiAllvariant rather than an alias;docs-old/dev/divergences.mdrecording the deviation and the reason;test_solo_multigene_umi_all_drops_cross_gene_umisasserting the correct result, never STAR's no-op.Only the
MultiGeneUMI_Allpath changes; the default (-) and the other modes produce identical output. If option 1 is preferred instead, the test asserts the behaviour either way and inverting it is a one-line change.