Skip to content

Releases: MesserLab/SLiM

Version 2.6

14 Jan 23:49
Compare
Choose a tag to compare

We have just released SLiM 2.6. This is a major release with a bunch of new stuff. Here are the major new features and changes:

  • Eidos now supports matrices (2-D) and arrays (n-D), with new functions related to matrices/arrays such as array() and matrix(), cbind() and rbind(), dim() and nrow() and ncol(), and matrixMult(). The way matrices/arrays work in Eidos is very parallel to how they work in R. See the new Eidos manual, sections 2.9 and 3.7, for details.
  • SLiM now supports periodic spatial boundary conditions, in which the modeled space wraps around at one or all edges to form a seamless, continuous space. This boundary condition can be extremely useful for theoretical models in particular, since it eliminates "edge effects" that exist with any other boundary condition. See the new recipe 14.12 for discussion and an example model.
  • SLiMgui now supports making haplotype plots, and the chromosome view now supports an alternative haplotype-based display mode. See the new, revised recipe 13.5 for an example of using these features.
  • SLiMgui now supports visualization of the distribution of fitness effects for mutation types, so you can see a plot of the DFE directly and verify that it looks how you expect. See the revised section 7.1 of the SLiM manual for discussion and examples.
  • Eidos now has an rdunif() function for drawing from a discrete uniform distribution, and rmvnorm() for drawing from a multivariate normal distribution.
  • The Eidos core has been optimized considerably, leading to as much as a 20% speedup for Eidos-intensive models. (If your model spends most of its time in the SLiM core, as many models do, this will make no difference to you.)
  • The function that used to be named apply() is now named sapply(), following R's naming conventions more closely. A new function named apply() has been added for executing code on the margins of a matrix/array, like the R function apply(). If your code uses the old apply() function, you will be shown an error message suggesting that you switch to using sapply() instead, following the rename.

There are a bunch of other changes, some of which may be important to you; see the revision history in the SLiM manual (chapter 23) for a more complete list.

In addition to the recipes mentioned above, we've got some other new/modified recipes:

  • Recipe 13.9 (tracking true local ancestry along the chromosome) has been revised, with supporting modifications in the SLiM core, to be much faster. True local ancestry can now be tracked along a fairly long chromosome; there is still a speed penalty, but it should not be prohibitive for many applications.
  • Recipe 13.12 (modeling nucleotides) has similarly been revised, with supporting SLiM revisions, to be much faster. You can now model explicit nucleotide bases along a fairly long chromosome, albeit still with some speed penalty of course.
  • Recipes have been added to show how one might model microsatellites in SLiM (recipe 13.15) and how one might model transposons (recipe 13.16).
  • A new recipe, 13.17, shows how to model multiple phenotypic traits based upon QTLs, with pleiotropy and mutational correlation based upon an M-matrix that governs the mutational effects of each QTL mutation.

A handful of minor bugs was fixed in this release. The only one that might affect simulation results from SLiM 2.5 is that the mutation frequencies/counts from the mutationFrequencies() and mutationCounts() methods of SLiMSim could be wrong immediately after a call to addMutations() or removeMutations(), until the next fitness-recalculation generation cycle stage. This would not occur after a call to addNewMutation() or addNewDrawnMutation(), only after addMutations() or removeMutations(); it is thus expected to impact few, if any, end users. If your model does use those particular calls in a way that would have been unsafe, however, you should redo all runs.

You can obtain SLiM 2.6 from the SLiM home page at http://messerlab.org/slim/ ; note that the manuals, recipes, and reference sheets have also undergone revisions.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Benjamin C. Haller
Messer Lab
Cornell University

Version 2.5

14 Jan 23:50
Compare
Choose a tag to compare

We have just released SLiM 2.5. This is a major release with a bunch of new stuff. First of all, for all users, it is important to note:

  • This release fixes a bug present in 2.4, 2.4.1, and 2.4.2 that would cause incorrect addition of mutations in models that involved clonal reproduction. If you did not call setCloningRate() in your model, this bug will not have affected you, but if you were using clonal reproduction with 2.4, 2.4.1, or 2.4.2 you should consider all results from those runs to be suspect. Apologies for this very bad bug, which slipped through the cracks due to a flaw in my test code (which has been fixed). As always, it is wise to verify that your results make sense, since bugs do happen!
  • We have started a new online repository called SLiM-Extras, for useful code and resources related to SLiM, at https://github.com/MesserLab/SLiM-Extras. It has a couple of useful tidbits already, and we hope that the SLiM user community (that's you!) will contribute more.

Here are the major new features and changes:

  • You can now write your own Eidos functions, and call them from your SLiM code! This makes it easier to encapsulate code into reuseable packages, and to organize the code in your model. Chapter 4 of the new Eidos manual covers this feature in detail, and recipe 11.1 in the new SLiM manual provides an example. SLiM-Extras (see above) now has reuseable functions for calculating FST and mean nucleotide heterozygosity.
  • The mutation rate can now vary along the chromosome, with a mutation-rate map similar to the existing recombination map, and this map can be displayed in SLiMgui.
  • The Mutation class now supports the getValue()/setValue() mechanism that many other SLiM classes already possess, for greater extensibility.
  • SLiMgui can now prettyprint your code (i.e., fix its indentation to look nice), with a button in the toolbar directly above the script editor view.
  • Eidos has several new language features, including block comments with /* */ and a "ternary conditional" operator, ?else. See the new Eidos manual for details.
  • A new function, source(), can be used to read and execute Eidos code contained in a file
  • The SLiM and Eidos documentation now have hyperlinks in their tables of contents, for easier navigation
  • Improvements to various Eidos functions: pmax(), pmin(), max(), min(), range(), seq(), any(), all(), unique(). All changes are backward-compatible. Check the new documentation if you care.
  • A bug fix for a flaw in InteractionType; spatial queries could return incorrect results if two individuals had an identical coordinate value. Not all coordinates had to be identical between the individuals; any individual coordinate being identical could trigger the bug. If you use integer coordinate values, or if offspring in your model inherit a spatial coordinate from a parent without modification, you might care, otherwise this bug is very unlikely to matter to you.

We've also got some new recipes:

  • 13.13: a model of haploid organisms in SLiM
  • 13.14: a model of variation in functional density along the chromosome, using the new mutation-rate-map feature in an unusual way

You can obtain SLiM 2.5 from the SLiM home page at http://messerlab.org/slim/ ; note that the manuals, recipes, and reference sheets have also undergone revisions.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.4.2

14 Jan 23:51
Compare
Choose a tag to compare

Hi all. A quick announcement that SLiM version 2.4.2 has just been released. This is a bug fix release for a serious bug; upgrading is STRONGLY RECOMMENDED FOR ALL USERS.

The bug causes mutation identifiers, which should be unique to each mutation across an entire model run, to instead be reused in a random fashion. For one thing, this means that the mutation ids given by SLiM's standard output commands may be duplicated and non-unique, causing downstream analysis issues. For another, because SLiM relies upon the mutation ids to identify segregating mutations within a sample, this bug means that the particular mutations that are output may themselves be incorrect; some mutations that are in fact segregating may not be included in the output.

These two problems mean that output from SLiM 2.4.1 cannot be trusted. This problem was also present in SLiM 2.4, but it was not present in SLiM 2.3 and earlier; it was introduced in 2.4. Model runs in version 2.3 and earlier are thus unaffected by this bug. Model runs done in 2.4 or 2.4.1 should be re-run.

My apologies for this bug. I test SLiM extensively, but it is very difficult to catch some types of bugs since SLiM is intrinsically stochastic in nature; there is no canonically correct output for a given SLiM model, making some types of testing problematic. As always when using third-party software, please do extensive sanity checks on the results you get from SLiM to make sure it is working as intended for you.

Thanks to Andrew Sackman for reporting the problem.

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.4.1

14 Jan 23:51
Compare
Choose a tag to compare

Hi all. A quick announcement that SLiM version 2.4.1 has just been released. This is a bug fix release; unfortunately SLiM 2.4 made it out the door with a fairly bad bug that needs immediate patching.

The bug affects simulations that use multiple subpopulations. In this case, the subpopID of mutations added to the simulation with addNewMutation() or addNewDrawnMutation() could be incorrect (mutations added by SLiM would have the correct subpopID). In addition, if a subpopulation was removed by calling setSubpopulationSize(0), a crash or other undefined behavior could result.

Simulations that do not use multiple subpopulations, or that did not use addNewMutation(), addNewDrawnMutation(), or SubpopulationSize(0), should run without problems in SLiM 2.4. Nevertheless, upgrading is strongly recommended to avoid any possibility of error.

Apologies for the bug, and thanks to Kieran Samuk for reporting the problem quickly, allowing us to fix it before version 2.4 had been out for long. :->

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.4

14 Jan 23:51
Compare
Choose a tag to compare

We have just released SLiM 2.4. This is a major release with a bunch of new stuff. First of all, for all users, it is important to note:

  • This version fixes build issues on Linux with the 2.3 release; sorry about that. It won't happen again, I hope, as we are now using TravisCI to validate our builds on Linux.
  • It also fixes a potentially serious bug in the Eidos function setDifference() that could lead to undefined behavior (crashes, memory corruption, etc.) for models that use that function. If your model does not use that function in its script, this is guaranteed to be of no importance to you; the bug was very clearly localized to that function. If your model does use that function, however, we recommend that you upgrade to version 2.4 immediately, and that you consider all output from SLiM 2.3 and earlier, from your models that used the setDifference() function, to be suspect. We apologize for this.
  • Please note that this version may result in changed model behavior and model output even given the same random number seed. This is not a bug; it is due to improvements in the SLiM engine. If you need exact backward compatibility of behavior and output, you should not upgrade. (This is usually true of major updates to SLiM, but I've decided to start pointing it out in the release notes so nobody is surprised.)

OK, with those points out of the way, here are the major new features and changes:

  • we've done extensive internal optimizations that should lead to better performance of many models (and for even better performance, see the new "mutation runs" feature, section 16.4 in the SLiM manual)
  • SLiMgui can now do runtime profiling of models, letting you see which parts of your script are causing performance problems
  • a system() function has been added to Eidos, allowing your script to run arbitrary Unix commands
  • using system(), you can now do custom plotting in R with live plot updating in SLiMgui; see the new recipe 13.11
  • we added a raft of new methods, functions, and properties: sumOfMutationsOfType() for fast QTL effect addition, writeTempFile() for creating randomly named temporary files, catn() and paste0() for simpler output generation
  • incidental selfing in hermaphroditic models (where the same individual happens to be chosen as the first and second parent in a biparental mating event) can now be disabled with a preventIncidentalSelfing option to initializeSLiMOptions()
  • some new display options for the chromosome view and population view have been added to SLiMgui; access them through the context menu on those views by control-clicking or right-clicking on the views.
  • MutationType, GenomicElementType, and InteractionType now support the getValue()/setValue() paradigm that already existed on some other SLiM classes, allowing them to be tagged with arbitrary new auxiliary properties
  • a new mutationStackGroup property has been added to SLiM to allow more complex mutation-stacking strategies in models that want very tight control over the way new mutations are added to the chromosome

We've also got some new recipes:

  • 9.5: Changing selection coefficients with setSelectionCoeff() for temporal variation in selection
  • 13.11: live plotting in SLiMgui with R using system()
  • 13.12: Modeling nucleotides in SLiM

There are many smaller feature additions and other minor changes; a more complete change list may be found in chapter 23 of the SLiM manual, and even more detail is in the VERSIONS file in the source code on GitHub.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.3

14 Jan 23:52
Compare
Choose a tag to compare

We have just released SLiM 2.3. This is a major release with a bunch of new stuff:

  • New feature: support for continuous space. Each subpopulation can now, optionally, define a spatially continuous area in 1, 2, or 3 dimensions, and individuals can occupy positions within that area as defined by new x, y, and z properties on the Individual class. Spatial maps can be defined that establish environmental values at spatial positions across that area – e.g., temperature, carrying capacity, or optimum phenotype. Extensive examples are given in the recipes in chapter 14 of the new SLiM manual.
  • New feature: interactions. SLiM will now assist you in defining interactions between individuals, which can be non-spatial or can depend upon the positions of individuals in continuous space if that new feature is also used. It is simple to set up things like phenotype-based competition, spatial mate choice, etc., using this feature. A new Eidos class, InteractionType, is now available to model such interactions, and a new callback type, the interaction() callback, has been added to allow interactions to be modified with arbitrary Eidos script. Extensive examples are given in chapter 14 of the new manual.
  • New feature: fitness() callbacks can now be defined to apply to a mutation-type of NULL, which makes them "global" fitness() callbacks that are called once per individual, regardless of the mutations possessed. Recipes 13.1, 13.3, 13.10, and some of the new recipes in chapter 14 now illustrate the use of this technique, which makes it unnecessary to use marker mutations in many situations that previously required them, such as additive QTL models.
  • Policy change: readFromPopulationFile() no longer has the side effect of recalculating fitness values, and warns if it is called at a time other than a late() event. This tightens things up regarding how populations are saved and read back in, to avoid problematic issues related to the addition of interactions. If you rely on fitness values being calculated immediately by readFromPopulationFile(), or call it at a time other than a late() event, your script may need to change. As a side effect of this, the Import Population... command in SLiMgui has also been removed; if you want to import a population, use readFromPopulationFile() in your script.
  • Minor change: outputFull() will now output positional information if continuous space is enabled, and readFromPopulationFile() will restore that information, making it easier to restart simulations using continuous space.
  • Minor change: mateChoice() callbacks can now return a vector of all zero mating weights to reject the first parent, equivalent to returning float(0)
  • Minor change: mateChoice() callbacks can now return a singleton Individual to indicate that that individual is to be chosen as the second parent, rather than having to create a whole mating weights vector, simplifying and speeding up some mate choice algorithms.
  • Minor change: some color-conversion functions have been added to Eidos to allow conversion between RGB and HSV color systems, etc., making it easier to make models that look nice in SLiMgui when using spatial maps and other such features.
  • Bug fixes: fixes for minor issues with code completion, syntax coloring, and the subset operator [] in Eidos, none of which would have negatively affected simulations run in previous SLiM versions
  • Optimizations: ifelse(), operator !, and mean() are now somewhat faster

You can obtain SLiM 2.3 from the SLiM home page at http://messerlab.org/slim/ ; note that the manuals have also undergone major revisions.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.2.1

14 Jan 23:52
Compare
Choose a tag to compare

We have just released SLiM 2.2.1. This is a minor release, but provides a bunch of nice new stuff, so it is recommended for most users:

  • The biggest news is that SLiMgui is now a proper document-based app. The extension ".slim" is now used for SLiM model files in SLiMgui, although the command-line tool will continue to accept files with any extension. To use your existing model files in SLiMgui, please ensure that they have an extension of ".slim" so that they are recognized. SLiMgui can now perform commands like save, revert, etc., on model files, treating them as normal documents, rather than the rather strange way SLiMgui used to work.
  • The recycle button in SLiMgui now highlights green when changes have been made to the script and it has not yet been recycled, as a reminder.
  • A tag property of type float, named tagF, has been added to Individual for storage of custom state of type float
  • Command-line constant definitions (see section 14.2) now allow arbitrary expressions
  • A function named order() has been added to Eidos to provide sorting indices, like the R function of the same name
  • Properties (color, colorSubstitution) were added to allow custom coloring of individuals, genomic element types, and mutation types in SLiMgui (see recipe 7.4)
  • Some performance optimizations related to vectorized access of properties have been added, speeding up some models by a factor of up to 3x
  • Syntax coloring in SLiMgui has been sped up considerably for large model files; nevertheless, it can always be turned off in SLiMgui's prefs
  • Code completion now works properly again on OS X 10.12 after Apple made a change that broke it; invoke it by pressing in SLiMgui
  • Making multiple calls to initializeRecombinationRate() is now explicitly illegal, to clarify the existing initialization policy in SLiM 2
  • A hang when all individuals have fitness <= 0 has now been converted into an error log and termination, for easier debugging

In addition, there are a bunch of new recipes in SLiM 2.2.1:

  • Forcing a pedigree during mating (recipe 13.7)
  • Suppression of baseline hermaphroditic selfing (recipe 12.4)
  • Estimating model parameters using Approximate Bayesian Computation with R (recipe 13.8)
  • Tracking true local ancestry along the chromosome (recipe 13.9)
  • A quantitative genetics model with heritability (recipe 13.10)
  • Custom coloring of a model in SLiMgui (recipe 7.4)

You can obtain SLiM 2.2.1 from the SLiM home page at http://messerlab.org/slim/ ; note that the manuals and reference sheets have also undergone minor revisions.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.2

14 Jan 23:53
Compare
Choose a tag to compare

We have just released SLiM 2.2. This is a major release; it has only a couple of very minor bug fixes (version 2.1.1 was a good stable release), but it has major performance improvements and several new features, so it is recommended. Details:

  • Performance improvements when running SLiM models, due to rearchitecture of an aspect of the underlying genetic model. This can result in as much as a 2-3x speedup for many models, according to my testing. Models that spend a lot of time in Eidos code (in callbacks, say) will not see much difference, however.
  • Performance improvements for SLiMgui, due to a switch to using OpenGL to draw the chromosome view. This can decrease drawing overhead by more than 50%, making performance in SLiMgui much closer to the performance of the same model running at the command line.
  • Added a new type of callback, the recombination() callback, for altering SLiM's proposed recombination breakpoints on a per-gamete level. This can be used to model chromosomal inversions (see the new recipe 13.5), evolution of recombination, and other such effects.
  • Added a new containsMarkerMutation() on Genome, for fast checking for the presence/absence of "marker" mutations of a known mutation type at a known position (again see recipe 13.5 for an example).
  • Added a new function, clock(), to Eidos that gives the current CPU usage of the process. This is useful for measuring the amount of processor time used by particular sections of code, or by your whole model; see section 15.2 in the new manual for discussion.
  • Added a dictionary-like setValue()/getValue() mechanism to Individual, Subpopulation, and SLiMSim to let you assign values to named keys on those objects. This is like a more general and powerful (but somewhat slower) version of the already existing "tag" facility, and is useful when you have more than one piece of model state that you need to attach to those objects. See recipe 11.1 in the new manual for an example of using this.
  • Added a new command-line option, -define (or -d), that lets you define Eidos constants on the command line that will exist throughout your model run. This is very useful for doing bulk runs of a model while varying particular parameter values, varying the random number seed systematically, and so forth. See section 14.2 of the new manual for discussion.
  • Added a "tips & tricks" panel to SLiMgui that appears on launch, providing various tips on SLiMgui's more obscure and hidden features. I know, I hate these too – but you can get rid of it by checking the "don't show this again" checkbox. Seriously, though, some of the tips might prove very useful to you – if you don't know how to use code completion in SLiMgui you are really missing out – so you might want to tolerate the annoyance at least briefly. :->
  • Minor bug fixes and improvements, none worth mentioning here; see the version notes on GitHub for more information if you really care.

You can obtain SLiM 2.2 from the SLiM home page at http://messerlab.org/slim/ ; note that the manuals, recipes, and reference sheets have also undergone corresponding revisions.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.1.1

14 Jan 23:53
Compare
Choose a tag to compare

We have just released SLiM 2.1.1. This is a minor release, but contains fixes for a couple of important bugs, so it is strongly recommended that everyone update to it:

  • Fix for a crash when using very large recombination maps
  • Fix for various fatal errors when sex is enabled in some situations, particularly when mateChoice() or modifyChild() callbacks are used
  • Fix for a crash when accessing the individuals in a subpopulation after the subpopulation has been resized
  • Make MS output be sorted by the mutations' positions (a fix to a regression introduced in 2.1)
  • Add a -mutationCounts() method on SLiMSim, parallel to the -mutationFrequencies() method, to get integer frequency counts for mutations
  • Fix some build issues on Linux with gcc 5.4.0

You can obtain SLiM 2.1.1 from the SLiM home page at http://messerlab.org/slim/ ; note that the manuals have also undergone minor revisions.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University

Version 2.1

14 Jan 23:53
Compare
Choose a tag to compare

We have just released SLiM 2.1. This is a major release with a bunch of new features. Some of these changes break backward compatibility, and thus may require minor changes on your end for your existing scripts to continue to work, so please review this list carefully:

  • Output from SLiM has been overhauled and greatly improved. Output methods now allow output to be sent to a file (either overwriting or appending to an existing file at that path), and new output methods on the Genome class make it easy to output a custom set of genomes, sampled or chosen in any way you wish (see section 17.3.2 and recipe 4.2.3). Output in VCF format is now supported, in addition to the previously existing SLiM and MS formats (see recipe 4.2.2 and sections 17.3.2, 17.11.2, and chapter 19). These changes break backward compatibility in two ways: (1) If you were calling Subpopulation's methods outputSample() or outputMSSample() and passing in a requestedSex parameter in a sexual simulation, your call will break because a new "replace" parameter has been added before requestedSex, controlling whether to sample with or without replacement; and (2) If you were processing SLiM-format output with your own post-processing scripts, you may need to slightly modify those scripts, because the output format has changed a little. The new format includes a field for Mutation objects that gives an identifier for each mutation. This identifier is unique, and remains constant for a given mutation throughout a run. It is therefore very useful for tracking the progress of a given mutation through multiple output dumps; but it does change the output format, potentially breaking downstream scripts. The new format is document in section 19.1.1.
  • As mentioned in the first item, a unique identifier has been added to Mutation (and is carried over into Substitution) to track particular mutations throughout a simulation run. A user-settable tag property has also been added to Mutation and Substitution, allowing you to tag mutations with whatever extra piece of information you wish, as with other tag properties in SLiM. See section 17.7.1 for details on these new properties.
  • The readFromPopulationFile() method of SLiMSim now sets the simulation generation as a side effect, using the information from the loaded file, since this is almost always what one wants. This change breaks backward compatibility for scripts that relied on the generation not being changed by this call. See section 17.10.2 for details.
  • A new class, Individual, has been added to SLiM. It provides the ability to handle simulations at an individual level, rather than a genome level, since often it is convenient to have the two genomes of a diploid individual "travel together". You can draw a sample of individuals from a subpopulation easily now, for example, or easily determine whether an individual contains a given mutation in either of its genomes. This class is documented in section 17.6, and recipes in sections 4.2.3, 9.4.2, 9.4.3, 9.4.4, 11.1, 12.1, 13.1, 13.2, and 13.3 now use this class – it has proved to be extremely useful!
  • To support the new Individual class, fitness() and mateChoice() and modifyChild() callbacks all now have access to pseudo-parameters giving the focal individual or individuals involved in the callback. See the documentation on writing callbacks for details, in sections 18.2–18.4.
  • The new Individual class now optionally supports pedigree-based tracking of relatedness between individuals. This facility may be turned on with a new initialization call, initializeSLiMOptions() (see section 17.1). If enabled, individuals may then be asked for pedigree-related information through new properties (section 17.6.1), and may be asked to assess their relatedness to other individuals using the new relatedness() method (section 17.6.2). Pedigree tracking may slightly slow down model execution, so it is disabled by default, but typical models are unlikely to see any appreciable speed impact, so please don't hesitate to use this feature. A new recipe, section 13.2, shows how to use the relatedness() function to promote inbreeding.
  • A new DFE type, "s", has been added to MutationType. This allows you to supply any Eidos code snippet to calculate selection coefficients for the mutation type, making it possible to define any DFE you wish rather than being limited to the set of supported options; see section 17.8 for details. A new recipe in section 13.1 uses this facility to define a mutation type that has a selection coefficient of either -1 or +1 (used to construct a quantitative trait in SLiM through an additive genetics model, which is mostly what that recipe is about).
  • Sex-specific recombination rates and/or recombination maps are now supported by SLiM, for sexual models where recombination differs between the sexes. See sections 17.1 and 17.2.
  • Eidos has been extended to now allow default arguments and named arguments for function calls and method calls. This is a fairly big change to the language, but backward compatibility has been preserved. You can use these new features if you wish, or not. Named arguments can be quite useful for making your code more readable, however, and default arguments are helpful in conjunction with named arguments in allowing you to specify only those parameters for which you wish to supply a non-default value. Read sections 2.7.3 through 2.7.6 of the Eidos manual (not the SLiM manual!) for an introduction to this feature.
  • Eidos was also extended to better support a particular type of method call, a non-multicasted class method call that operates on a vector of the class. This has little practical impact for users; it is mostly an under-the-hood change that makes the language a little more powerful and useful. A discussion of this language feature is in section 2.8.6 of the Eidos manual.
  • The one substantial impact of the previous point (improvement of non-multicasted class method calls) for most users is that the Genome methods addNewMutation() and addNewDrawnMutation() have been changed from instance methods to class methods. If anyone was depending upon these calls to multicast out across a vector and create a new, different mutation for each genome in a vector, this change will break backward compatibility (but we doubt that anyone was relying on this). For everyone else, it will actually make life simpler. To add a new mutation to a bunch of genomes, in an introduction event, it used to be necessary to add the mutation to one genome, get the new mutation back from that call, and then add that object to all of the other target genomes using addMutation(). This dance is no longer necessary; a single call to addNewMutation() or addNewDrawnMutation() on a whole vector of genomes now adds a single new mutation to all of the genomes, which is virtually always what one wants. This new paradigm for introducing mutations is now used in recipes throughout the SLiM manual; see recipes 9.4.4 and 12.2, for example.
  • Eidos has some new functions. There are now deleteFile() and createDirectory() functions, making support for file I/O in Eidos more complete. There are also new methods for set operations (union, intersection, difference, and symmetric difference) in Eidos. That can be quite useful if you want to find out which mutations two genomes have in common, which are unique to each genome, which mutations in genome A are missing from genome B, etc.; those are of course all set operations. These new functions are all documented in chapter 3 of the Eidos manual.
  • Eidos also now has a size() method in the superclass of all SLiM classes, so instead of size(object) you can do object.size(). This is purely a semantic nicety; the two ways of finding out the number of elements in an object vector are equivalent.
  • SLiMgui's fitness ~ time plot is improved, with separate display of subpopulation fitnesses, and an option for plotting of either points or lines (accessible through the context menu, with a right-click or control-click on the graph).
  • Code completion in SLiMgui is now quite a bit smarter. It can be used to complete off of defined variables – SLiM knows what type of object the variables reference. It can be used to complete off of functions that return objects, such as sample() – SLiM knows what object type the function will return. Just press escape to bring up the code completion feature. Please let us know if you find cases that don't work well.
  • For teaching and demo purposes, it is now possible to hide the script/output area in SLiMgui, with a command under the Script menu.
  • All recipes in the SLiM manual are now available directly in SLiMgui; just select them from the Open Recipe submenu of the File menu. This makes it much easier to follow along with the recipes in the SLiM cookbook.
  • Various bug fixes, minor improvements, and performance optimizations. Some particular types of models may see a substantial speedup in SLiM 2.1. One bug that has been fixed might be important for some users. The Genome method containsMutations() could return incorrect results if it was passed a non-singleton vector of mutations to check for. It worked fine if passed a singleton mutation, which is the common usage pattern, so probably nobody was affected by this bug, but you might check your model code to be sure.

You can obtain SLiM 2.1 from the SLiM home page at http://messerlab.org/slim/; note that the manuals, reference sheets, and recipes have also undergone revisions. We recommend that you remove all old SLiM reference materials from your machine, to avoid confusion.

If you have any questions, comments, etc., please use the slim-discuss group for that. Thanks, and happy modeling!

Cheers,

Ben Haller
Messer Lab
Cornell University