Times to fixation and loss

27 views
Skip to first unread message

Dan Schrider

unread,
Jun 24, 2021, 12:14:16 AM6/24/21
to slim-discuss
Hi Ben,

We are trying to record the times to fixation/loss for every mutation in our slimulation--basically all of the data underlying the histograms that SLiM nicely plots for you. I know this is straightforward to do for fixations because we have the origin and fixation times recorded for each, but what is the best way to get this for losses so we can, say, record all of this in a log file?

Thanks, and all the best!

Dan

Ben Haller

unread,
Jun 24, 2021, 12:34:15 AM6/24/21
to slim-discuss
Hi Dan!

As of SLiM 3.5, there is a good way to do this.  With that version, it became possible to keep long-term references to Mutation objects, and monitor their status (segregating, fixed, etc.).  So all you need to do is (1) before the point in the generation cycle when mutations would potentially be lost, retain all of the extant mutations, and (2) after that point in the generation cycle, look at the mutations you retained, determine which have been lost, and log out the information you need about them.  Here's an example (apologies for the formatting, Blogger helpfully removes all tabs):

initialize() {
initializeMutationRate(1e-8);
initializeMutationType("m1", 0.5, "f", 0.0);
initializeGenomicElementType("g1", m1, 1.0);
initializeGenomicElement(g1, 0, 99999);
initializeRecombinationRate(1e-8);
}
1 {
sim.addSubpop("p1", 500);
}
early() {
// remember all the mutations that exist now
defineGlobal("MUTS", sim.mutations);
}
late() {
// log out mutations that have been lost
lost = MUTS[!MUTS.isSegregating & !MUTS.isFixed];
for (mut in lost)
catn(sim.generation + ": lost id " + mut.id + " at position " + mut.position);

// let go of the retained mutations
rm("MUTS");
}
100000 late() { }

The rm() call is not strictly necessary; it just undefines the MUTS global variable, and thus allows SLiM to reclaim the memory taken by all Mutation objects that have been removed from the simulation.  If it is omitted, everything will still work, but the peak memory usage of the model might be slightly higher.  I included it as an illustration of best practices, but it is non-essential.

The same approach should work in a nonWF model as well, given that mortality (and thus loss of mutations) also occurs between early() and late() events.  Let me know if you have any questions about how this works!  (Or if you encounter any issues with it; I believe this machinery all works, but you will be one of the first to actually use it, so.  :->)

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


Dan Schrider

unread,
Jun 24, 2021, 1:52:12 PM6/24/21
to slim-discuss
Thanks Ben! That looks great, and we will compare to the GUI's histograms just to confirm and let you know how it goes.
Reply all
Reply to author
Forward
0 new messages