bodkan/slendr

Add SLiM's selfing rate function to slendR?

Closed this issue · 3 comments

ornobalam commented

Hi Martin,

We briefly talked about this during the Copenhagen workshop. Here is how I am adding selfing after running the slim() function with method = "gui":

function (void) create_pop(object pop) {
pop_id = pop.getValue("pop_id");

if (pop.getValue("parent") ==  "ancestor") {
    log_output("creating " + pop.getValue("pop") + "(p" + pop.getValue("pop_id") + ")");
    sim.addSubpop(pop_id, pop.getValue("N"));
    **get_pop(pop_id).setSelfingRate(0.96);**
} else {
    log_output(
        "split of " + pop.getValue("pop") + "(p" + pop.getValue("pop_id") + ")" +
        " from " + pop.getValue("parent") + "(p" + pop.getValue("parent_id")  + ")"
    );
    sim.addSubpopSplit(pop_id, pop.getValue("N"), pop.getValue("parent_id"));
    **get_pop(pop_id).setSelfingRate(0.96);**

}

This is adding selfing globally to all populations when they're created. We discussed possibly adding an argument inside the population() function to set the selfing rate for each population.

Best,
Ornob

bodkan commented

Thank you for the suggestion, Ornob! This will be very easy to do. I'll post an update once I get to it.

It was very nice meeting you!

ornobalam commented
bodkan commented

Sooo, as much as this will probably be a disappointment for some, I have decided against adding this feature (already a while ago, actually).

Even if it means narrowing down the set of use cases without hacking on the built-in SLiM script -- which is always possible by spawning a SLiM gui or better by providing a path to a customized slendr SLiM script in compile_model() -- I would prefer to maintain parity between slim() and msprime() wherever possible. Adding engine-specific parameters to either of those functions for relatively rare-case scenarios would make slendr internals much more complex.

Adding support for running all slendr models through msprime() -- which ended up to be a surprisingly popular feature of slendr -- has made me re-evaluate how large of a subset of SLiM's functionality should slendr adopt. The answer is: "much less than I originally envisioned".

That being said, I am still planning to add seamless support for extending the built-in SLiM script from the R side, by plugging in bits of user-defined SLiM code. This won't require changes to slendr's R interface, while making the range of possible SLiM simulations much wider (including the functionality mentioned in this issue).

  • 👍1