Closed mmelchers closed 10 months ago
Hi @mmelchers Thanks for raising the ticket, I'll take a look ASAP
Regression test: run 10/10 search with match prediction on, and check it completes successfully and match prediction object is populated in results file.
Bug fix test - create donor with HLA described in ticket, but homozygous for the C-expressing allele, and then run 10/10 search using C-null allele. Donor should come back as 10/10 match, and have predicted OverallMatchCount
of 10.
08:02
)04:09N
)MatchPredictionResult.OverallMatchCount
of 10.Test passed
@zabeen Regression testing status: Ok
Describe the bug When performing comparison between Hap-E and ATLAS the following issue was found. To Reproduce Steps to reproduce the behavior: create search with HLA:![image](https://github.com/Anthony-Nolan/Atlas/assets/44259052/d64ce1e3-ffd4-46e5-864d-20c4ec212ab6)
perform 0 mismatch donor search in WMDA dev environment
Expected behaviour No donors returned with zero mismatch probability larger than 0%
Screenshots![image](https://github.com/Anthony-Nolan/Atlas/assets/44259052/60ca3cda-0224-4ebe-93cf-7bae5a5350d7)
Additional context Suggested info from the Hap-E developers: Of course, it has to do with the null allele in the patient typing. 04:09N is part of G code 04:01:01G. Below, I have listed the 5-locus genotypes for the first donor (in HF set 5). The difference between Hap-E and ATLAS lies in the most frequent genotype in the first line. Hap-E considers this genotype to have one mismatch to the patient on locus C: In the genotype, we have 04:01, while the patient has 04:09N. With high resolution null allele, we treat the patient as homozygous on locus C. So we would only consider a genotype with homozygous C08:02 or with C*08:02 + an explicit null allele to be a match.
ATLAS seems to classify the first genotype to be a match genotype to the patient – presumably because allele 04:09N is part of 04:01g. If I calculate f_genotype / f_overall = 3.80381E-07/4.29066E-07 = 88.6 I get the ATLAS p0 value.