Documentation for SLiM function initializeSLiMOptions, which is a method of the SLiM class Initialize. Note that the R function is a stub, it does not do anything in R (except bring up this documentation). It will only do anything useful when used inside a slim_block function further nested in a slim_script function call, where it will be translated into valid SLiM code as part of a full SLiM script.

initializeSLiMOptions(
  keepPedigrees,
  dimensionality,
  periodicity,
  mutationRuns,
  preventIncidentalSelfing,
  nucleotideBased,
  randomizeCallbacks
)

Arguments

keepPedigrees

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is F. See details for description.

dimensionality

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is "". See details for description.

periodicity

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is "". See details for description.

mutationRuns

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is 0. See details for description.

preventIncidentalSelfing

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is F. See details for description.

nucleotideBased

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is F. See details for description.

randomizeCallbacks

An object of type logical or string or string or integer or logical or logical or logical. Must be of length 1 (a singleton). The default value is F. See details for description.

Value

An object of type void.

Details

Documentation for this function can be found in the official SLiM manual: page 654.

Configure options for the simulation. If initializeSLiMOptions() is called at all then it must be called before any other initialization function (except initializeSLiMModelType()), so that SLiM knows from the outset which optional features are enabled and which are not. If keepPedigrees is T, SLiM will keep pedigree information for every individual in the simulation, tracking the identity of its parents and grandparents. This allows individuals to assess their degree of pedigree-based relatedness to other individuals (see Individual's relatedness() and sharedParentCount() methods, section 25.7.2), as well as allowing a model to find "trios" (two parents and an offspring they generated) using the pedigree properties of Individual (section 25.7.1). As a side effect of keepPedigrees being T, the pedigreeID, pedigreeParentIDs, and pedigreeGrandparentIDs properties of Individual will have defined values (see section 25.7.1), as will the genomePedigreeID property of Genome (see section 25.4.1). Note that pedigree-based relatedness doesn't necessarily correspond to genetic relatedness, due to effects such as assortment and recombination. For an overview of other ways of tracking genetic ancestry, including true local ancestry at each position on the chromosome, see sections 1.7 and 14.7. Beginning in SLiM 3.5, keepPedigrees=T also enables tracking of individual reproductive output, available through the reproductiveOutput property of Individual (see section 25.7.1) and the lifetimeReproductiveOutput property of Subpopulation (see section 25.16.1). If dimensionality is not "", SLiM will enable its optional "continuous space" facility. Three values for dimensionality are presently supported: "x", "xy", and "xyz", specifying that continuous space should be enabled for one, two, or three dimensions, respectively, using (x), (x, y), and (x, y, z) coordinates respectively. This has a number of side effects. First of all, it means that the specified properties of Individual (x, y, and/or z) will be interpreted by SLiM as spatial positions; in particular, SLiMgui will use those properties to display subpopulations spatially. Second, it allows spatial interactions to be defined, evaluated, and queried using initializeInteractionType() and interaction() callbacks. And third, it enables the use of any other properties and methods related to continuous space, such as setting the spatial boundaries of subpopulations, which would otherwise raise an error. If periodicity is not "", SLiM will designate the specified spatial dimensions as being periodic - wrapping around at the edges of the spatial boundaries of that dimension. This option may only be used if the dimensionality parameter to initializeSLiMOptions() has been used to enable spatiality in the model, and only spatial dimensions that were specified in the dimensionality of the model may be declared to be periodic (but if desired, it is permissible to make just a subset of those dimensions periodic; it is not an all-or-none proposition). For example, if the specified dimensionality is "xy", the model's periodicity may be "x", "y", or "xy" (or "", the default, to specify that there are no periodic dimensions). A one-dimensional periodic model would model a space like the perimeter of a circle. A two-dimensional model periodic in one of those dimensions would model a space like a cylinder without its end caps; if periodic in both dimensions, the modeled space is a torus. The shapes of three-dimensional periodic models are harder to visualize, but are essentially higherdimensional analogues of these concepts. Periodic boundary conditions are commonly used to model spatial scenarios without "edge effects", since there are no edges in the periodic spatial dimensions. The pointPeriodic() method of Subpopulation is typically used in conjunction with this option, to actually implement the periodic boundary condition for the specified dimensions. If mutationRuns is not 0, SLiM will use the value given as the number of mutation runs inside Genome objects; if it is 0 (the default), SLiM will calculate a number of mutation runs that it estimates will work well. Internally, SLiM divides genomes into a sequence of consecutive mutation runs, allowing more efficient internal computations. The optimal mutation run length is short enough that each mutation run is relatively unlikely to be modified by mutation/recombination events when inherited, but long enough that each mutation run is likely to contain a relatively large number of mutations; these priorities are in tension, so an intermediate balance between them is generally desirable. The optimal number of mutation runs will depend upon the machine and even the compiler used to build SLiM, so SLiM's default value may not be optimal; for maximal performance it can thus be beneficial to experiment with different values and find the optimal value for the simulation - a process which SLiM can assist with (see section 21.4). Specifying the number of mutation runs is an advanced technique, but in certain cases it can improve performance significantly. If preventIncidentalSelfing is T, incidental selfing in hermaphroditic models will be prevented by SLiM. By default (i.e., if preventIncidentalSelfing is F), SLiM chooses the first and second parents in a biparental mating event independently. It is therefore possible for the same individual to be chosen as both the first and second parent, resulting in selfing events even when the selfing rate is zero. In many models this is unimportant, since it happens fairly infrequently and does not have large consequences. This behavior is SLiM's default because it is the simplest option, and produces results that most closely align with simple analytical population genetics models. However, in some models this selfing can be undesirable and problematic. In particular, models that involve very high variance in fitness or very small effective population sizes may see elevated rates of selfing that substantially influence model results. If preventIncidentalSelfing is set to T, all such incidental selfing will be prevented (by choosing a new second parent if the first parent was chosen again). Non-incidental selfing, as requested by the selfing rate, will still be permitted. Note that if incidental selfing is prevented, SLiM will hang if it is unable to find a different second parent; there must always be at least two individuals in the population with non-zero fitness, and mateChoice() and modifyChild() callbacks must not absolutely prevent those two individuals from producing viable offspring. Enforcement of the prohibition on incidental selfing will occur after mateChoice() callbacks have been called (and thus the default mating weights provided to mateChoice() callbacks will not exclude the first parent!), but will occur before modifyChild() callbacks are called (so those callbacks may assume that the first and second parents are distinct). If nucleotideBased is T, the model will be nucleotide-based. In this case, auto-generated mutations (i.e., mutation types used by genomic element types) must be nucleotide-based, and an ancestral nucleotide sequence must be supplied with initializeAncestralNucleotides(). Nonnucleotide- based mutations may still be used, but may not be referenced by genomic element types. A mutation rate (or rate map) may not be supplied with initializeMutationRate(); instead, a hotspot map may (optionally) be supplied with initializeHotspotMap(). This choice has many consequences across SLiM; see section 1.8 for further discussion. If randomizeCallbacks is T (the default), the order in which individuals are processed in callbacks will be randomized to make it easier to avoid order-dependency bugs. This flag exists because the order of individuals in each subpopulation is non-random; most notably, females always come before males in the individuals vector, but non-random ordering may also occur with respect to things like migrant versus non-migrant status, origin by selfing versus cloning versus biparental mating, and other factors. When this option is F, individuals in a subpopulation are processed in the order of the individuals vector in each tick cycle stage, which may lead to order-dependency issues if there is an enabled callback whose behavior is not fully independent between calls. Setting this option to T will cause individuals within each subpopulation to be processed in a randomized order in each tick cycle stage; specifically, this randomizes the order of calls to mutationEffect() callbacks in both WF and nonWF models, and calls to reproduction() and survival() callbacks in nonWF models. Each subpopulation is still processed separately, in sequential order, so order-dependency issues between subpopulations are still possible if callbacks have effects that are not fully independent. This feature was added in SLiM 4, breaking backward compatibility; to recover the behavior of previous versions of SLiM, pass F for this option (but then be very careful about order-dependency issues in your script). The default of T is the safe option, but a small speed penalty is incurred by the randomization of the processing order - for most models the difference will be less than 1 the worst case it may approach 10 issue may therefore run somewhat faster if this is set to F. Note that anywhere that your script uses the individuals property of Subpopulation, the order of individuals returned will be non-random (regardless of the setting of this option); you should use sample() to shuffle the order of the individuals vector if necessary to avoid order-dependency issues in your script. This function will likely be extended with further options in the future, added on to the end of the argument list. Using named arguments with this call is recommended for readability. Note that turning on optional features may increase the runtime and memory footprint of SLiM.

Author

Benjamin C Haller (bhaller@benhaller.com) and Philipp W Messer (messer@cornell.edu)

Examples

## This just brings up the documentation:
initializeSLiMOptions()