Stdpopsim: Mutation rates/recombination rates required for humans

[jeromekelleher]

In homo_sapiens.py we have the length of each chromosome and placeholders for mutation and recombination rate data. Ideally, we'd like to have a mean rate that has been estimated for each chromosome. I'm not sure where we'd get this information for mutation rates.

[carjed]

I can take care of the mutation rates with data I generated for this paper—rather than per chromosome, would it be better to do it per 1Mbp window?

[jeromekelleher]

That sounds great @carjed! I think we want to have both ultimately --- support for mutation maps in msprime is in the pipeline, so having a map would be extremely useful. But we'd also want simple summaries too for people who don't need this level of detail.

[carjed]

cool, do you have a planned format for the mutation map implementation in msprime? A bed file (or files) with columns CHR START END RATE makes the most sense to me, but I can tweak it if needed.

[ndukler]

What license are we planning on releasing this under? If we're planning on using the GPL should we use pybedtools BedTool class which already probably has a bunch of useful functionality and optimizations?

[andrewkern]

I don't know that package but I'm fine with the GPL. Opinions on future license @jeromekelleher @petrelharp ?

[jeromekelleher]

What license are we planning on releasing this under? If we're planning on using the GPL should we use pybedtools BedTool class which already probably has a bunch of useful functionality and optimizations?

We're currently under MIT, but I really don't mind. GPL can be annoying in that it prevents some people from using your code, so in the interest of this being as widely used as possible I think a permissive license makes sense. But I don't feel strongly enough about it to argue the point at any more length than this.

I don't think we need a BED file dependency here for stdpopsim, the mutation rate map parsing will be done in msprime.

[jeromekelleher]

cool, do you have a planned format for the mutation map implementation in msprime? A bed file (or files) with columns CHR START END RATE makes the most sense to me, but I can tweak it if needed.

Anything like that is fine @carjed, there will be some sort of text input that will map to this scheme.

[agladstein]

We should resolve this before submitting the manuscript. If we don't have mutation maps by the publication, at least use the latest published overall mutation rate.

[petrelharp]

ping @carjed

[jeromekelleher]

A per-chromosome rate would be great. Let's no worry about maps, we can't do anything with them for now anyway (needs some upstream dev in msprime).

[apragsdale]

I didn't see this issue - there's been a lot of activity lately!

Per chromosome rates would be a nice feature to have, though I think the default behavior should be to use a constant genome-wide rate. I think the default simulations should be as simple as possible, and give users options to add complexity (such as variable mutation rates across the genome).

[jeromekelleher]

Per chromosome rates would be a nice feature to have, though I think the default behavior should be to use a constant genome-wide rate. I think the default simulations should be as simple as possible, and give users options to add complexity (such as variable mutation rates across the genome).

Totally agree we should keep things as simple as possible, but we do force the user to choose a particular chromosome (first listed, by default). Doesn't it make sense to get the mutation rate for that chrom then? That's what we do recomb rate.

[apragsdale]

Yeah, that does make sense to get mutation and recombination rates for each chromosome since we force users to pick a chromosome.

I guess I was thinking of the situation: if I want to simulate under a model, but just simulate say 100 1Mb chunks with some default genome-wide mutation rate, can I do that as it's currently constructed?

[jeromekelleher]

Not with the CLI, but you can with the Python API.

[jeromekelleher]

Closing this - I think we've covered humans.