Bug fix for periodic boundary condition models posted

[Ben Haller]

  Hello slim-announce subscribers.  I recently found a bug in SLiM 2.6, and this is an announcement about it.  The bug is not expected to bite many users, but when it does bite it can produce seriously incorrect results, so please read on.  The bug is specific to models that:

(a) use continuous space (not just discrete subpopulations), as enabled with the "dimensionality" option of initializeSLiMOptions(), AND

(b) enable periodic boundary conditions, using the "periodicity" option of initializeSLiMOptions(), AND

(c) use either the totalOfNeighborStrengths() OR the strength() methods of InteractionType, AND

(d) have either a fairly small population size (probably < 100), OR use a relatively long maximum interaction distance (or both)

  If your model satisfies ALL of those four preconditions, it is likely to be bitten by the bug (sorry!).  Models that satisfy (a) through (c) but not (d) might be bitten, but it is much less likely.  The symptom of the bug is that interaction distances and strengths can be incorrect; they can be much larger or much smaller than they ought to be.  This occurs because the periodic boundary conditions were not managed correctly in one section of SLiM's code.  If your model uses totalOfNeighborStrengths() or strength(), other InteractionType methods may also return incorrect results, because the internal data structures of the InteractionType will be corrupted; but if neither totalOfNeighborStrengths() nor strength() is ever called, other InteractionType methods will work correctly.

  If your model does not satisfy the above preconditions, there is no problem with SLiM 2.6 and you can continue to use it (doing all the sanity-checks on your model and results that you can, of course, as one always ought to when relying upon the correctness of software).  The bug is very well understood and is limited to the use case described.

  If your model might be bitten by the bug, on the other hand, you should download and build the current head version of the master branch of SLiM from GitHub (https://github.com/MesserLab/SLiM), and use that build rather than the release version of SLiM 2.6.  Instructions for building SLiM can be found in chapter 2 of the SLiM manual, including instructions for making your own build of SLiMgui in Xcode on Mac OS X.

  Since this bug will probably affect few, if any, end users of SLiM we have decided not to roll out a SLiM 2.6.1 release.  So far SLiM 2.6 seems quite solid apart from this one issue.

  Sorry for the inconvenience; please let me know if you have any questions.

Cheers,

Benjamin C. Haller

Messer Lab

Cornell University