Documentation for SLiM function addRecombinant, which is a method of the
SLiM class Subpopulation.
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.
addRecombinant(
strand1,
strand2,
breaks1,
strand3,
strand4,
breaks2,
sex,
parent1,
parent2,
randomizeStrands,
count,
defer
)An object of type null or Genome object. Must be of length 1 (a singleton). See details for description.
An object of type null or Genome object. Must be of length 1 (a singleton). See details for description.
An object of type null or integer. See details for description.
An object of type null or Genome object. Must be of length 1 (a singleton). See details for description.
An object of type null or Genome object. Must be of length 1 (a singleton). See details for description.
An object of type null or integer. See details for description.
An object of type null or float or string. Must be of length 1 (a
singleton). The default value is NULL. See details for description.
An object of type null or Individual object. Must be of length 1
(a singleton). The default value is NULL. See details for description.
An object of type null or Individual object. Must be of length 1
(a singleton). The default value is NULL. See details for description.
An object of type logical. Must be of length 1 (a
singleton). The default value is F. See details for description.
An object of type integer. Must be of length 1 (a singleton). The
default value is 1. See details for description.
An object of type logical. Must be of length 1 (a singleton). The
default value is F. See details for description.
An object of type Individual object.
Documentation for this function can be found in the official SLiM manual: page 735.
Generates a new offspring individual from the given parental genomes with the specified crossover breakpoints, queues it for addition to the target subpopulation, and returns it. The new offspring will not be visible as a member of the target subpopulation until the end of the offspring generation tick cycle stage. The target subpopulation will be used to locate applicable mutation() and modifyChild() callbacks governing the generation of the offspring individual (unlike the other addX() methods, because there are potentially up to four parental individuals to reference); recombination() callbacks will not be called by this method. This method is an advanced feature; most models will use addCrossed(), addSelfed(), or addCloned() instead. This method supports several possible configurations for strand1, strand2, and breaks1 (and the same applies for strand3, strand4, and breaks2). If strand1 and strand2 are both NULL, the corresponding genome in the generated offspring will be empty, as from addEmpty(), with no parental genomes and no added mutations; in this case, breaks1 must be NULL or zero-length. If strand1 is non-NULL but strand2 is NULL, the corresponding genome in the generated offspring will be a clonal copy of strand1 with mutations added, as from addCloned(); in this case, breaks1 must similarly be NULL or zero-length. If strand1 and strand2 are both non-NULL, the corresponding genome in the generated offspring will result from recombination between strand1 and strand2 with mutations added, as from addCrossed(), with strand1 being the initial copy strand; copying will switch between strands at each breakpoint in breaks1, which must be non-NULL but need not be sorted or uniqued (SLiM will sort and unique the supplied breakpoints internally). (It is not currently legal for strand1 to be NULL and strand2 non-NULL; that variant may be assigned some meaning in future.) Again, this discussion applies equally to strand3, strand4, and breaks2, mutatis mutandis. Note that when new mutations are generated by addRecombinant(), their subpopID property will be the id of the offspring's subpopulation, since the parental subpopulation is ambiguous in the general case; this behavior differs from the other add...() methods. The sex parameter is interpreted exactly as in addCrossed(); see that method for discussion. If the offspring sex is specified in any way (i.e., if sex is non-NULL), the strands provided must be compatible with the sex chosen. If the offspring sex is not specified (i.e., if sex is NULL), the sex will be inferred from the strands provided where possible (when modeling an X or Y chromosome), or will be chosen randomly otherwise (when modeling autosomes); it will not be inferred from the sex of the individuals possessing the parental strands, even when the reproductive mode is essentially clonal from a single parent, since such inference would be ambiguous in the general case. When modeling the X or Y, strand1 and strand2 must be X genomes (or NULL), and strand3 and strand4 must both be X genomes or both be Y genomes (or NULL). By default, the offspring is considered to have no parents for the purposes of pedigree tracking, since there may be more than two "parents" in the general case. If pedigree tracking of parentage is desired, parent1 and/or parent2 may be passed to explicitly establish particular individuals as the parents of the offspring for purposes of pedigree tracking. In this case, if only one of parent1 and parent2 is non-NULL, that individual will be set as both of the parents of the offspring, mirroring the way that parentage is tracked for other cases such as addCloned() and addSelfed(). It is not required for parent1 or parent2 to actually be a genetic parent of the offspring at all, although typically they would be. If randomizeStrands is F (the default), strand1 will be the initial copy strand when generating the first gamete to form the offspring, and strand3 will be the initial copy strand when generating the second gamete. If randomizeStrands is T, then if strand1 and strand2 are both non-NULL, 50 will be swapped, making strand2 the initial copy strand for the first gamete; and similarly, if strand3 and strand4 are both non-NULL, 50 will be swapped, making strand4 the initial copy strand for the second gamete. This is probably usually the desired behavior, to avoid an inheritance bias due to a lack of randomization in the initial copy strand, so passing T for randomizeStrands is recommended unless you specifically desire otherwise. It is not the default behavior only for reasons of backward compatibility. These semantics allow several uses for addRecombinant(). When all strands are non-NULL, it is similar to addCrossed() except that the recombination breakpoints are specified explicitly, allowing very precise offspring generation without having to override SLiM's breakpoint generation with a recombination() callback. When only strand1 and strand3 are supplied, it is very similar to addCloned(), creating a clonal offspring, except that the two parental genomes need not belong to the same individual (whatever that might mean biologically). Supplying only strand1 is useful for modeling clonally reproducing haploids; the second genome of every offspring will be kept empty and will not receive new mutations. For a model of clonally reproducing haploids that undergo horizontal gene transfer (HGT), supplying only strand1 and strand2 will allow HGT from strand2 to replace segments of an otherwise clonal copy of strand1, while the second genome of the generated offspring will again be kept empty; this could be useful for modeling bacterial conjugation, for example. Other variations are also possible. The value of the meanParentAge property of the generated offspring is calculated from the mean parent age of each of its two genomes (whether they turn out to be null genomes or not); that may be an average of two values (if both offspring genomes have at least one parent), a single value (if one offspring genome has no parent), or no values (if both offspring genomes have no parent, in which case 0.0 results). The mean parent age of a given offspring genome is the mean of the ages of the parents of the two strands used to generate that offspring genome; if one strand is NULL then the mean parent age for that offspring genome is the age of the parent of the non-NULL strand, while if both strands are NULL then that offspring genome is parentless and is not used in the final calculation. In other words, if one offspring genome has two parents with ages A and B, and the other offspring genome has one parent with age C, the meanParentAge of the offspring will be (A+B+C+C) / 4, not (A+B+C) / 3. Note that gene conversion tracts are not explicitly supported by this method; the breaks vectors provide crossover breakpoints, which may be used to implement crossovers or simple gene conversion tracts. There is no way to specify complex gene conversion tracts with heteroduplex mismatch repair. Beginning in SLiM 4.1, the count parameter dictates how many offspring will be generated (previously, exactly one offspring was generated). Each offspring is generated independently, based upon the given parameters. The returned vector contains all generated offspring, except those that were rejected by a modifyChild() callback. If all offspring are rejected, object<Individual>(0) is returned, which is a zero-length object vector of class Individual; note that this is a change in behavior from earlier versions, which would return NULL. Beginning in SLiM 4.1, passing T for defer will defer the generation of the genomes of the produced offspring until the end of the reproduction phase. Genome generation can only be deferred if there are no active mutation() callbacks; otherwise, an error will result. Furthermore, when genome generation is deferred the mutations of the genomes of the generated offspring may not be accessed until reproduction is complete (whether from a modifyChild() callback or otherwise). There is little or no advantage to deferring genome generation at this time (it is in place for future expansion); the default of F for defer is generally preferable since it has fewer restrictions. Also beginning in SLiM 4.1, in spatial models the spatial position of the offspring will be inherited (i.e., copied) from parent1; more specifically, the x property will be inherited in all spatial models (1D/2D/3D), the y property in 2D/3D models, and the z property in 3D models. Properties not inherited will be left uninitialized, as they were prior to SLiM 4.1. The parent's spatial position is probably not desirable in itself; the intention here is to make it easy to model the natal dispersal of all the new offspring for a given tick with a single vectorized call to pointDeviated(). If parent1 is NULL (the default), parent2 will be used; if it is also NULL, no spatial position will be inherited. Note that this method is only for use in nonWF models. See addCrossed() for further general notes on the addition of new offspring individuals.
This is documentation for a function in the SLiM software, and has been reproduced from the official manual, which can be found here: http://benhaller.com/slim/SLiM_Manual.pdf. This documentation is Copyright © 2016-2020 Philipp Messer. All rights reserved. More information about SLiM can be found on the official website: https://messerlab.org/slim/
Other Subpopulation:
Subpopulation,
addCloned(),
addCrossed(),
addEmpty(),
addSelfed(),
addSpatialMap(),
cachedFitness(),
configureDisplay(),
defineSpatialMap(),
outputMSSample(),
outputSample(),
outputVCFSample(),
pointDeviated(),
pointInBounds(),
pointPeriodic(),
pointReflected(),
pointStopped(),
pointUniform(),
removeSpatialMap(),
removeSubpopulation(),
sampleIndividuals(),
setCloningRate(),
setMigrationRates(),
setSelfingRate(),
setSexRatio(),
setSpatialBounds(),
setSubpopulationSize(),
spatialMapColor(),
spatialMapImage(),
spatialMapValue(),
subsetIndividuals(),
takeMigrants()