Skip to content

Version 2.1
Compare
Choose a tag to compare
@bhaller bhaller released this 14 Jan 23:53
· 3340 commits to master since this release
v2.1
381b8e3

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

Assets 8
Loading