Error when using tree sequence recording in conditional simulations

[Olivia Johnson]

Hi everyone,

Following the new update, I have found that my conditional simulation that includes tree sequence recording returns an error when it restarts if the condition could not be met. The error is  "(Species::_InstantiateSLiMObjectsFromTables): (internal error) remembered_genomes_ is not empty" and it invalidates the simulation. I think I need to clear the individuals from the memory when the simulation restarts, but I'm not sure how to do that.

I have adapted recipe 9.2 such that it returns the same error (see minimal example below).

Any suggestions as to how I may overcome this error would be greatly appreciated.

Thanks

Olivia

// Minimal example: Conditional simulation with tree sequence recording

initialize() {

   initializeMutationRate(0);

   initializeMutationType("m1", 0.0, "f", 0.0);// introduced mutation

   initializeGenomicElementType("g1", m1, 1.0);

   initializeGenomicElement(g1, 0, 99999);

   initializeRecombinationRate(1e-8);

   

   initializeTreeSeq();

}

1 early() {

   // save this run's identifier, used to save and restore

   defineConstant("simID", getSeed());

   

   sim.addSubpop("p1", 500);

}

1000 late() {

   // save the state of the simulation

   sim.treeSeqOutput(tempdir() + "slim_" + simID + ".trees");

   

   // introduce the sweep mutation

   target = sample(p1.genomes, 1);

   target.addNewDrawnMutation(m1, 10000);

}

1000:100000 late() {

   rInd= sample(p1.individuals, 10);

   sim.treeSeqRememberIndividuals(rInd);

   if (sim.countOfMutationsOfType(m1) == 0)

   {

       fixed = (sum(sim.substitutions.mutationType == m1) == 1);

       

       if (fixed)

       {

           cat(simID + ": FIXED\n");

           sim.simulationFinished();

       }

       else

       {

           cat(simID + ": LOST at " +sim.cycle+" - RESTARTING\n");

           

           // go back to tick 1000

           sim.readFromPopulationFile(tempdir() + "slim_" + simID + ".trees");

           

           // start a newly seeded run

           setSeed(rdunif(1, 0, asInteger(2^62) - 1));

           

           // re-introduce the sweep mutation

           target = sample(p1.genomes, 1);

           target.addNewDrawnMutation(m1, 10000);

       }

   }

}

[Ben Haller]

Hi Olivia!  This looks like a bug, indeed.  I guess it is triggered by remembering individuals and then reloading; some state should be getting reset that is not getting reset, I think.  Nice that we have an assert that catches the problem when it happens, that's convenient.  :->  Could you open a GitHub issue about this, with the same info you just posted?  That way we're connected to you as we work on a fix.  Thanks very much for the report!  Hopefully I can get it fixed quickly for you.

(Hot tip for SLiM users: in general, I try to make error messages say "(internal error)" when they are something that should never go wrong; when you see that, it's a solid indication that you have found a real bug and you might as well go straight to filing a GitHub issue.  When an error message does not say that, that means that I think that error is at least possible to be caused by your script, not by a bug in SLiM itself.  In other words, "(internal error)" messages come from SLiM's internal checks that the SLiM core itself is functioning as designed – which, in this case, it is not.)

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


Olivia Johnson wrote on 8/25/22 9:28 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/e7eb6a08-50da-4d7b-a0ba-8469ce2f3312n%40googlegroups.com.

[Ben Haller]

Hi all.  A followup regarding the bug that Olivia reported in SLiM 4.0.  It was a trivial error in the code, but the consequences are somewhat large.  This bug will bite you IF you use tree-sequence recording AND reload saved state using readFromPopulationFile() (as simulations of sweeps conditional on establishment/fixation typically do).  In that case, IF you remembered individuals with treeSeqRememberIndividuals() you will get an error, as Olivia did.  If you do NOT remember individuals, you will not get an error, but each reload will leak the memory for the old tree sequence, so your simulation might chew through quite a lot of memory, quite quickly, which could also be a big problem.  As far as I can tell this bug would never result in incorrect simulation results; just the error/leak; still, if you were bitten by the bug it would probably be a good idea to re-run your simulations just in case.

So.  If your model does those things – tree-seq recording AND reloading from disk – then you should use the current GitHub head version of SLiM 4 (see the manual, chapter 2, for instructions on building SLiM from sources).  This bug will come out in the next SLiM release, whenever that happens.  Sorry for the hiccup; this fell through the cracks between the tests I run, which I will remedy!  :->

Thanks for the very useful bug report, Olivia!  Always good to have a clean, simple reproducible case.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University