codecov[bot]
commented
4 months ago Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 90.43%. Comparing base (
8366b03) to head (79d9871). Report is 4 commits behind head on main.
Additional details and impacted files
```diff @@ Coverage Diff @@ ## main #156 +/- ## ========================================== + Coverage 90.40% 90.43% +0.03% ========================================== Files 11 11 Lines 3198 3210 +12 ========================================== + Hits 2891 2903 +12 Misses 307 307 ```:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR is motivated by an attempt to fix #113 and a few other associated problems.
Interestingly, the linked issue has also manifested in normal, "non-truncated" models if those had more complex setups (multiple resize events, gene-flow events, etc). The root cause of the problems was a numerical issue in converting "forward time units" (like, events in years C.E. 1400 -> 1800 -> 2024 -> 2100...) into "generations backwards in time" in msprime. Basically, if a "starting time" of a forward simulation wasn't something like 1 (as is often the case in simple models with events specified in generation times) but a larger number like "start in year 1900", these times weren't properly converted into correct "generations in the past" in the context of a coalescent simulation.
In these instances msprime simply crashed with a "negative times not valid" error.
This also fixed related problems when plotting models, such as visualizing "truncated" models (438bd2 and e8cdf5).
Another note: if a "truncated" model is being simulated -- i.e. model which has event scheduled at time X but the simulation is being run for only time X where X < Y -- events that are scheduled after the simulated end will be simply dropped. This has always been the case with SLiM simulations (effectively, if a user calls
sim.simulationFinished(), any other script blocks at a later time wouldn't fire), so this behavior now matches what's going on on the msprime side of things.None of this changes the behavior of slendr until this point, only fixes previous instances of a) slendr simulations crashing, b) model visualizations showing clear plotting artifacts.