Invoking fitness effect of mutation type

[Rafal Gutaker]

Hello Ben and others,

I am back to SLiM after 2 years gap and got real stuck with multiplicative fitness of certain mutation type.

I am trying to isolate the fitness effect of deleterious mutations from overall fitness. sumOfMutationsOfType(m1) gives me additive effect, but can I get multiplicative effect in a similar fashion for a single mutation type? 

cachedFitness(NULL) allows subselecting individuals, but does not allow subselecting mutations.

Would the only solution be to use fitness callback to zero all non m1 mutations fitness effects? This is not desirable  because I would like to track the load from m1 in time, keeping the effect of other mutations on individual fitness.

Many thanks for your help!

[Ben Haller]

Hi Rafal!  (Welcome back!  :->)

There is a proposal along these lines, which you can see here:

https://github.com/MesserLab/SLiM/issues/387

Until that issue is fixed, what you want to do is somewhat difficult.  As you mention, you could have a mutationEffect() callback for all of the *other* types, making them all neutral.  You could use the `active` property of SLiMEidosBlock to deactivate those callbacks all the time except when you want to do this custom fitness calculation; then activate the callbacks, recalculate the fitness values with recalculateFitness(), get those recalculated values with cachedFitness(), and then deactivate all the callbacks again.  (Note that SLiM automatically activates all script blocks at the start of each tick, so you'd need to have a first() event to deactivate them at the start of each tick right after SLiM activates them for you.)  You'd also need to make sure that SLiM actually uses its own fitness values, not your special ones; you might need to call recalculateFitness() again to make that happen, since otherwise the fitness caches would have your special values in them, depending on the tick cycle stage when you did all this.  I think that would probably work, but obviously it's a pain, and would also be somewhat inefficient and bug-prone – which is why that issue is there in GitHub, of course.  :->  It would be helpful if you would comment on that issue, indicating whether or not the new method as proposed would be useful to you, and what other features you'd like to see added to it.  Or, if I've misunderstood what you need entirely, please do post again.  Thanks!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


Rafal Gutaker wrote on 9/18/25 10:56 AM:

--
SLiM forward genetic simulation: http://messerlab.org/slim/
Before posting, please read http://benhaller.com/slim/bugs_and_questions.html
---
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 visit https://groups.google.com/d/msgid/slim-discuss/d5071ae9-414c-4233-b155-89efff5c55cdn%40googlegroups.com.

[Rafal Gutaker]

Thanks Ben, yes, that should achieve the effect that I am after. Can I double check, if this would 'zero' the selectionCoeff/fitness of other mutation types only temporarily, i.e. in the next generation, SLIM would remember what their value was? Also, what is the advantage of `active` property of SLiMEidosBlock over simply defining mutationEffect callback only for a single generation, e.g. 10000 mutationEffect(m2) {return 1.0;} ?

Thanks,
Rafal

[Ben Haller]

Hi Rafal,

Sorry, your email was held up in moderation for a while before Google Groups bothered to notify me of it.  As always, when this happens people can always email me to tell me that their post has been blocked, and ask me to unblock it.

To your points:

(1) Yes, the normal fitness effects would resume the next time that fitness values are recalculated without your special mutationEffect() callback(s) enabled.

(2) Defining a mutationEffect() callback for one tick makes SLiM use that callback for that tick, for the fitness values that it calculates.  Those fitness values then affect the SLiM simulation – they are used by SLiM as the fitness values for the individuals in the simulation.  If that is fine with you, then that suffices.  What I understood you to be saying was that you wanted more control than that; you wanted to be able to calculate fitness values "on the side" that are *different* from the fitness values that you want SLiM to use.  The `active` property gives you control over which events/callbacks are active at any given time; in particular, in this situation, it gives you the ability to turn your mutationEffect() callback on, recalculate fitness values using it, get those fitness values, and then turn your callback off and recalculate fitness values again, without the callback, so that the fitness values used by SLiM are not affected by the shenanigans you're pulling behind its back.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

Rafal Gutaker wrote on 9/22/25 4:08 AM:

To view this discussion visit https://groups.google.com/d/msgid/slim-discuss/eded26b3-25dd-4df7-b0e2-b582e359af4fn%40googlegroups.com.