`addNewDrawnMutation( )` improperly vectorized about slim

[petrelharp]

This appears to be a problem in tree sequence recording and not about SLiM's internal state. Furthermore, trying to reload a tree sequence file with this problem results in the Inconsistent mutations error, so there is no chance of invisible errors in SLiM simulation; only in analyzing which of the output mutations are SLiM mutations or not.

[petrelharp]

After some printf debugging...

• the problem is that derived_mutation_ids_at_position( ) is returning the wrong thing sometimes
• that is because this method assumes that the mutations are in order by position in the thing they're looking in
• and so, deleteing the two lines starting here fixes the error

The problem seems to occur because the mutations we are adding go to a single genome not in order by position (position 9 comes before position 2). Changing the recipe to do

    balancing_pos = sort(sample(0:(chr_len-1), 2));

also fixes the problem.

I don't understand the ramifications here, so I'm not proposing a fix.

[bhaller]

Nice debugging. Yes, the sort order of mutations in the genomes gets corrupted, and that is an error in SLiM's internal state, not just in the tree-seq stuff. I think I just neglected to consider that the positions given to addNewDrawnMutation() might not be in sorted order, and that case didn't get tested somehow. I have modified the addNewDrawnMutation() code to sort the mutations before adding them, when necessary.

[petrelharp]

Thanks - I was pretty pleased with my debugging also. =)

[bhaller]

A quick look-over of the code didn't reveal anything obviously wrong, so this will require more thorough delving. Stay tuned.

[bhaller]

Interesting. I'm not sure whether/how/why the recorded TS information would be any different between the two patterns of Eidos calls, though, so the bug itself does presumably reside in SLiM's code...