Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

annotate_mutations #103

Open
petrelharp opened this issue Sep 16, 2020 · 2 comments
Open

annotate_mutations #103

petrelharp opened this issue Sep 16, 2020 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@petrelharp
Copy link
Contributor

To allow msprime to add nucleotide mutations, we could (a) use msprime to add nucleotide mutations, and then (b) convert these to SLiM nucleotide mutations. To do this, we'd need a pyslim method (pyslim.annotate_nucleotide_mutations?) that assigns SLiM IDs and moves the nucleotide itself from derived state to metadata.

Maybe this should be just part of a more general function (pyslim.annotate_mutations) that would do other modifications to the mutation metadata, like drawing selection cofficients from some distribution.

@bhaller
Copy link
Collaborator

bhaller commented Sep 16, 2020

This sounds reasonable. My only comment, really, is a big one: it's a shame that mutations in msprime and SLiM are in such completely different worlds. That they follow completely different paradigms, are represented in completely different ways, etc. It puts pyslim in a rather difficult position, although so far it seems to be working surprisingly well. I guess there is no solution to this, really, since both SLiM and msprime seem like they're pretty committed to their respective approaches, and changing either one would mean massive breakage and loss of backward compatibility. But it is nevertheless a shame, and I wonder whether there's some big-picture rethink that would improve things. Some way of bringing both paradigms together under a single unifying umbrella, or something.

@petrelharp
Copy link
Contributor Author

Well, tskit's model is really just SLiM's "last" stacking policy. It's the "stack" policy that's different. If SLiM was always on "stack" mode then I might suggest having tskit use that mode optinonally also (ie, treat a node's genotype as "all mutations above it" instead of "most recent mutation above it"). But given that SLiM does both, and also more complicated things, I think the way it is is Pretty Good.

@petrelharp petrelharp added this to the v1.0 milestone Mar 10, 2021
@petrelharp petrelharp modified the milestones: v1.0, v1.1 Dec 15, 2021
@bhaller bhaller added the enhancement New feature or request label Aug 10, 2022
@petrelharp petrelharp modified the milestones: v1.0, v1.1 Aug 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants