"Saving" model conditions after burn-in period
18 views
Skip to first unread message
Darren Li
Nov 10, 2025, 4:58:34 PM (13 days ago) Nov 10
to slim-discuss
Dear SLiM community,
A lot of times when running genetic models, a "burn-in period" is included at the beginning of the simulation to allow genetic equilibrium to take place before the main experiment. And often, this "burn-in period" takes a significant amount of the simulation running time, which makes me wonder, if I want to use the same initial conditions for different experiments, does it seem reasonable to "save" the model conditions (number of individuals in each population, mutations, etc.) after the spin-up period, and then for my other experiments "load" these conditions to run them?
Thank you!
Best regards,
Darren
Ben Haller
Nov 10, 2025, 5:20:28 PM (13 days ago) Nov 10
to Darren Li, slim-discuss
Hi Darren!
Yes, some form of this is commonly done. You can save and load the simulation state in both tree-sequence recording models and regular (nono-treeseq) models in SLiM; see, e.g., sections 9.2 and 18.3 of the SLiM manual.
If you really want multiple experiments to start from the exact same initial conditions, then this is very simple: burn in once, save the state, and then load that state and simulate onward for each experiment.
More often one wants to start from a model state generated stochastically by the same burn-in procedure, but not from the exact same initial conditions (the exact genetic state of which individuals possess which mutations at which frequencies, etc.). In this case, simply burning in once and reloading that state for each experiment could be problematic; it could result in pseudoreplication issues because the experiments are not really independent. For example, suppose your burn-in is non-neutral, and at the end of the burn-in there is a beneficial mutation captured mid-sweep. Every experiment run from the burn-in would have the same sweep, in the same location etc., and that would be likely to bias the results of the experiments to be more similar to each other than would be expected from fully independent simulation runs. This is obvious with a mutation captured mid-sweep; but it could be a (probably smaller) issue for a neutral burn-in too, depending upon what exactly you're doing – your research questions and the analysis you're doing on your simulation results. So it's something to think about. Depending on how much this worries you, you might need to do completely independent burn-ins, or you might decide the pseudoreplication issue is not a concern for you and so you can share a single burn-in; or there are intermediate options like:
- for every ten experiment runs do one shared burn-in, reducing the compute for your burn-ins by 10x while still having lots of independence between your runs (and you could even analyze whether the runs sharing a burn-in produce results more similar than runs that don't, telling you whether it matters)
- do a single long burn-in run, saving off new saved states periodically to use as initial states for different experiments; if you decide you should burn in for at least 10N generations, for example, where N is the population size, then you might do a single burn-in run where you save off state at 10N, 11N, 12N, ... xN where x suffices to give each of your experiments a different starting state. This sort of procedure wouldn't completely remove the possibility of pseudoreplication issues, but it ought to mitigate it considerably, while still cutting your compute time for burn-in by about 10x.
Lots of ideas in this area, lots of people doing different things. I am not aware of any comprehensive study of the pros and cons of different approaches, or of how much of a problem the pseudoreplication issue is for different test statistics and such. That'd be a worthwhile thing for somebody to do, probably, similarly to the recent studies looking at the pros and cons of model rescaling techniques!
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
Darren Li wrote on 11/10/25 4:58 PM:
Yes, some form of this is commonly done. You can save and load the simulation state in both tree-sequence recording models and regular (nono-treeseq) models in SLiM; see, e.g., sections 9.2 and 18.3 of the SLiM manual.
If you really want multiple experiments to start from the exact same initial conditions, then this is very simple: burn in once, save the state, and then load that state and simulate onward for each experiment.
More often one wants to start from a model state generated stochastically by the same burn-in procedure, but not from the exact same initial conditions (the exact genetic state of which individuals possess which mutations at which frequencies, etc.). In this case, simply burning in once and reloading that state for each experiment could be problematic; it could result in pseudoreplication issues because the experiments are not really independent. For example, suppose your burn-in is non-neutral, and at the end of the burn-in there is a beneficial mutation captured mid-sweep. Every experiment run from the burn-in would have the same sweep, in the same location etc., and that would be likely to bias the results of the experiments to be more similar to each other than would be expected from fully independent simulation runs. This is obvious with a mutation captured mid-sweep; but it could be a (probably smaller) issue for a neutral burn-in too, depending upon what exactly you're doing – your research questions and the analysis you're doing on your simulation results. So it's something to think about. Depending on how much this worries you, you might need to do completely independent burn-ins, or you might decide the pseudoreplication issue is not a concern for you and so you can share a single burn-in; or there are intermediate options like:
- for every ten experiment runs do one shared burn-in, reducing the compute for your burn-ins by 10x while still having lots of independence between your runs (and you could even analyze whether the runs sharing a burn-in produce results more similar than runs that don't, telling you whether it matters)
- do a single long burn-in run, saving off new saved states periodically to use as initial states for different experiments; if you decide you should burn in for at least 10N generations, for example, where N is the population size, then you might do a single burn-in run where you save off state at 10N, 11N, 12N, ... xN where x suffices to give each of your experiments a different starting state. This sort of procedure wouldn't completely remove the possibility of pseudoreplication issues, but it ought to mitigate it considerably, while still cutting your compute time for burn-in by about 10x.
Lots of ideas in this area, lots of people doing different things. I am not aware of any comprehensive study of the pros and cons of different approaches, or of how much of a problem the pseudoreplication issue is for different test statistics and such. That'd be a worthwhile thing for somebody to do, probably, similarly to the recent studies looking at the pros and cons of model rescaling techniques!
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
Darren Li wrote on 11/10/25 4:58 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/ed81e9c5-98f4-4ad2-86b6-3cbed6fef34bn%40googlegroups.com.
Darren Li
Nov 12, 2025, 4:42:22 PM (11 days ago) Nov 12
to slim-discuss
Dear Ben,
This is very useful, thank you!
Best regards,
Darren
Reply all
Reply to author
Forward
0 new messages