Aldy does not recognize [23936, A>G, rs7088784]

[lonny1999]

Hi!

When running Aldy, the tool does not recognize [23936, A>G, rs7088784], a variant characteristic for *3.002. I checked my input file manually and found 5 variants also present in PharmVar. However, Aldy only picks up 4 of those 5 and does not return [23936, A>G, rs7088784].
I checked the cyp2c19.yml file of the Aldy resources;

The variant is there, so that is not the problem.
Did someone maybe encounter the same?

[inumanag]

Hi @lonny1999,

This is a minor variant that does not define *3 in this case. It is only listed in the minor detection step (minor variants are usually listed in the output file only, not on the screen).

What is the output you get (both -o and on-screen output)? I can take a look to see if it is really there.

[lonny1999]

Thank you for your prompt reply! @inumanag

The output (both -o and the on-screen output) do not show the minor variant. Other variants that do define *3 are not in my input, only the [23936, A>G, rs7088784] variant is there.

Please find attached screenshots of my output and snippets of my input file on which the variants detected by Aldy are present and the one not detected in blue.

(I'm sorry for my late reply, I had to check what data I could share here)

[inumanag]

Seems that you do not have all major *3 variants: rs4986893 and rs144036596 are not present in the output. That means that *3 is not present in the sample (it is only present if all functional mutations are there).

Since rs7088784 is minor and associated with *3 in the database, Aldy won't report it if it cannot find *3 at all (minor mutations are only reported if their parent allele is present; major mutations, on the other hand, are always included).

You can force-tweak this by adding rs7088784 to the *1 section in the YML file; Aldy will be able to report it in that case.

I will see if I can fix this in the next version so that manual tweaks are no longer necessary.

[lonny1999]

Thank you very much for the clear explanation and advice! Very logical for Aldy to work that way. A tweak for this in the next version would be really convenient indeed!

In the meantime (after some more genotype calling with Aldy) I noticed that, when the variants of a sample do not completely match, this is reported by '+rsnumber' in the output behind the active allele. Is it indeed true that this '+rsnumber' is always/by default added to the active starallele? (so in case of *1/*2 it's added to *1 and in case of *17/*2 to *17?)

Besides, I got a little bit confused by the *17 section in the YML file of cyp2c19 since there are four variants there, while in PharmVar there are only three. When following the cited resource link, this also brings me to the PharmVar page only displaying three variants for *17.001 (in GRCh38). After looking more into this, I found out that rs11188072 is not in the current PharmVar, but is present in the archived cyp alleles and is also a variant according to literature. Anyway, I thought I would mention it here :)

[inumanag]

"+rs" part is only added to major star alleles in the presence of another functional SNP that is not part of the definition. e.g. 17+rsXY/2 is basically *17 with additional rsXY and *2. Note that in the current version, +rs can be added equally likely to both 17 and 2 (in the Aldy 4 that is currently in beta we actually try to phase these cases, however the phasing only works if you have long enough reads to cover the SNP distance). So you can treat such calls as "17/2 and some functional rsXY that can belong to either allele" in Aldy 3.

Thanks for the report. I am planning to refresh PharmVar definitions these days anyways :)

[inumanag]

PharmVar is refreshed in #31. Closing this issue—please reopen if still experiencing the problems.