Summary
A handful of alleles that netMHCpan -listMHC reports cannot be requested through mhctools, because the mhcgnomes-backed normalizer can't parse the name. Requesting one raises AlleleParseError during predictor construction (in BasePredictor._check_hla_alleles → normalize_allele_name), even though netMHCpan itself lists them as supported.
This is the tail left over after #219, which made ~2,456 non-human alleles usable by round-tripping netMHCpan's own -listMHC spelling. Those all normalize (just to a spelling netMHCpan rejects, which #219 fixed). The names below don't normalize at all, so they have no canonical identity for mhctools to key on.
Affected names (netMHCpan 4.2 -listMHC, 21 total)
BoLA-AW10 BoLA-D18.4 BoLA-HD6 BoLA-JSP.1 BoLA-T2C BoLA-T2a BoLA-T2b
BoLA-T2c BoLA-T5 BoLA-T7 BoLA-amani.1 BoLA-gb1.7
H-2-Qa1 H-2-Qa2 H2-Qa1 H2-Qa2
HLA-A30:14L
Mamu-B12 Mamu-B17 Mamu-B20 Mamu-B22
(mhcgnomes.parse() actually accepts most of these — e.g. H-2-Qa1 → H2-T23, HLA-A30:14L → HLA-A*30:14L — but the mhctools AlleleName compatibility shim in allele_normalization.py rejects AlleleWithoutGene, bare Gene, and annotation-suffixed results.)
Why it's not a one-liner
mhctools uses the normalized allele name as identity everywhere:
- input validation / homozygous dedup (
_check_hla_alleles),
- output parsing (
parsing.py:226 and :647 call normalize_allele_name with no fallback and would raise on these names),
- result matching (
_check_results).
Supporting un-normalizable alleles means carrying the raw -listMHC name as identity for those cases: validate verbatim against the raw supported set (already available post-#219 as self._supported_allele_names), pass the raw name on the command line (already the behavior via _cli_allele_name), and make the stdout parser fall back to the raw name when normalization fails.
Caveat
netMHCpan is itself inconsistent here — it lists Mamu-B12 but rejects it on -a ("cannot be found in allelenames list"), so full support isn't achievable from mhctools' side regardless.
Priority
Low — niche non-human research alleles. Filing to track; the common human-HLA and the round-trippable non-human cases already work as of 3.18.0 (#219).
Summary
A handful of alleles that
netMHCpan -listMHCreports cannot be requested through mhctools, because the mhcgnomes-backed normalizer can't parse the name. Requesting one raisesAlleleParseErrorduring predictor construction (inBasePredictor._check_hla_alleles→normalize_allele_name), even though netMHCpan itself lists them as supported.This is the tail left over after #219, which made ~2,456 non-human alleles usable by round-tripping netMHCpan's own
-listMHCspelling. Those all normalize (just to a spelling netMHCpan rejects, which #219 fixed). The names below don't normalize at all, so they have no canonical identity for mhctools to key on.Affected names (netMHCpan 4.2
-listMHC, 21 total)(
mhcgnomes.parse()actually accepts most of these — e.g.H-2-Qa1→H2-T23,HLA-A30:14L→HLA-A*30:14L— but the mhctoolsAlleleNamecompatibility shim inallele_normalization.pyrejectsAlleleWithoutGene, bareGene, and annotation-suffixed results.)Why it's not a one-liner
mhctools uses the normalized allele name as identity everywhere:
_check_hla_alleles),parsing.py:226and:647callnormalize_allele_namewith no fallback and would raise on these names),_check_results).Supporting un-normalizable alleles means carrying the raw
-listMHCname as identity for those cases: validate verbatim against the raw supported set (already available post-#219 asself._supported_allele_names), pass the raw name on the command line (already the behavior via_cli_allele_name), and make the stdout parser fall back to the raw name when normalization fails.Caveat
netMHCpan is itself inconsistent here — it lists
Mamu-B12but rejects it on-a("cannot be found in allelenames list"), so full support isn't achievable from mhctools' side regardless.Priority
Low — niche non-human research alleles. Filing to track; the common human-HLA and the round-trippable non-human cases already work as of 3.18.0 (#219).