Simulating single-locus dynamics

[Hanbin Lee]

Dear community members

Before moving onto a more general case involving recombination, I'm willing to simulate a single locus. In msprime, it is better to simulate with `sequence_length=1` for each loci and concatenating them. Otherwise, `recombination_rate=0.5` makes the simulation awfully slow.

In SLiM, I have read in the manual to set the recombination rate to 0.5. I wonder if this is slower than concatenating multiple single-locus simulations like in msprime. 

If so, a following question is, how could I collect multiple tree sequences generated from many single-locus simulations out of SLiM to obtain a single tree sequence? I now get tens of thousands of temporary tree sequences in my hard drive. I wonder if this could be done in a more tidy fashion. I imagine something like running multiple separate loci inside a single slim run by creating many subpopulations for each locus.

Thanks!

[Hanbin Lee]

Of course, it would be best if the process can be parallelized across loci as interactions between loci are not of interest at the moment. The naive approach to run many separate simulations and concatenate can be done by executing python multiprocessing under the subprocess call. Is it even possible to not write the tree sequence to the hard drive and directly transfer the output to Python in memory? 

[Ben Haller]

Hi Hanbin!

I'm not aware of anybody having tested it, but my guess is that using r=0.5 with a single simulation will be a clear win over doing separate 1-site simulations and concatenating them.  SLiM is quite different from msprime in that objects representing individuals and genomes and so forth get created and torn down with each generation of forward simulation.  With N 1-locus simulations you'd be paying that price N times, and I doubt any other speedup you might get would be worth it.  You'd also be paying the price of simplifying, writing out the tree sequence, etc., N times.  Using r=0.5 certainly does slow SLiM down considerably, compared to a much lower recombination rate; but I don't see any reason to expect that N separate 1-site simulations would be faster.  If you do a speed comparison, though, I'd be interested to hear how it goes!

But that's all running single-threaded.  As you say, this might be affected by parallelization, for sure.  If you want to simulate 1000 sites, and you have 1000 cores at your disposal, then you can do 1000 separate 1-site SLiM simulations simultaneously.  That would doubtless be faster than using one core to do one 1000-site SLiM simulation – probably much faster.  Of course then you get the filesystem clutter, and the cost of concatenating the 1000 tree sequences back together again, and so forth.  So doing this for just 2 sites would probably not be a win, both in terms of overall runtime and pipeline complexity; doing it for 1000 is very probably a win.  I don't know where the crossover is where it becomes worthwhile, and to some extent that's subjective (how much pain you experience from the filesystem clutter etc. :->).  Again, I'm not aware of anybody having tested such possibilities; please do report back if you do!  (And no, there is no way to do a single SLiM run utilizing multiple cores at the present time, so that's not an option here.  Maybe some day!)

For N 1-site simulations, I don't see any obvious way to avoid the large number of temporary tree sequences, no.  And no, there is no way to pipe the generated tree sequences directly into Python.  That would be nice, but I have no idea how it would work.  (If you or someone else has a proposal for how this could be implemented usefully, please of course open a GitHub issue!  It sounds like a cool and useful idea, I just don't know enough about Python and tskit-in-Python to have the slightest idea how it could be done.)

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


Hanbin Lee wrote on 11/8/25 1:15 PM:

--
SLiM forward genetic simulation: http://messerlab.org/slim/
Before posting, please read http://benhaller.com/slim/bugs_and_questions.html
---
You received this message because you are subscribed to the Google Groups "slim-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to slim-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/slim-discuss/6c3506f2-4ad1-46a1-a23d-effbe6f92f6dn%40googlegroups.com.