Spatial non-WF model - avoiding center

[Luca Soldini]

Hello Ben,

To add some brief context, I was in the Ancona workshop and I was the one working with the weird reproductive modes (which includes genome elimination etc.). Since the issue does not stem from that part -at least from my understanding-, I will not go into more details concerning that part.

The issue I have is with the spatial behaviour of individuals, which seem to avoid the center of the map.  I've found some ways to avoid this pattern (e.g., by increasing the dispersal standard deviation from 0.02 to 0.4), but this is not biologically relevant, and I am not sure I understand the reason why the individuals avoid being in the center of the map -would you have any insights on this please ?

The model includes some spatial competition, spatial mate choice, and low level of offspring dispersal. It is in 2 dimensions, and the boundaries are periodic. The whole code is attached as a .txt file.

Thanks again for the workshop, the software and the documentation.

Luca

[Ben Haller]

Hi Luca!  For one thing, I think you've got an issue with this line:

    p1.individuals.setSpatialPosition(p1.pointUniform(size(p1)));

The size(p1) call doesn't do what you want it to do.  The size of p1 is 1; it is a vector of length 1, containing just one subpopulation.  The number of individuals in a subpopulation can be obtained from the individualCount property, so try this instead:

    p1.individuals.setSpatialPosition(p1.pointUniform(p1.individualCount));

The other problem in your model relates to this detail in the doc for addRecombinant():

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 deviatePositions() / pointDeviated().  If parent1 is NULL (the default), parent2 will be used; if it is also NULL, no spatial position will be inherited.

You aren't specifying the parents of the offspring individuals in your calls to addRecombinant(), so they are ending up being whatever uninitialized memory contains – often zero, thus favoring the corner.  If you add appropriate parent information to your addRecombinant() calls, your model should then work fine.  :->  Perhaps this particular situation ought to cause an error; I'll think about that.  Happy modeling!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


Luca Soldini wrote on 6/7/24 5:33 PM:

--
SLiM forward genetic simulation: http://messerlab.org/slim/
---
You received this message because you are subscribed to the Google Groups "slim-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to slim-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/slim-discuss/c9b0e93a-ee94-4754-9a34-faf9cc6681cfn%40googlegroups.com.

[Luca Soldini]

Hi Ben,

Thanks for the reply and spotting the errors. It is indeed not the behaviour I was wishing for (since the parent1 and parent2 were withing brackets . I've now made the modifications as you suggested, and everything seems to work as expected!

Concerning the possibility of an error message, in my case I think I made this error because the parent1 and parent2 arguments are within brackets [] in the help of addRecombinant(). I guess I was thinking that, somehow, the parent ID and position would be retrieved from the genomes specified. However, by reading through the help now, it is indeed quite clear that " Properties not inherited will be left uninitialized" :)

Cheers,

Luca

[Peter Ralph]

Hi, Luca - the reason seems to be that the spatial position of offspring is not being set explicitly. So, the spatial positions that offspring get are obtained from random bits that happen to be in that chunk of memory. Then, when they are moved with

  p1.deviatePositions(offspring, "periodic"...)

this seems to move them mostly to the corners of the habitat (probably because those are usually the  nearest points to "random bits".

If you insert

offspring.setSpatialPosition(individual.spatialPosition);

every time an offspring is produced, it fixes the problem.

(This was a puzzling one! And I think Ben is on vacation, so thought I'd jump in here. =)

happy slimulating!

 Peter

--