When using -mixture, [E] is fast forwarded in the way [T] is

[hmedina]

Kappa Simulator: v4.0rc1-414-gfc032a0

The behavior of -mixture has several bugs.

Let's take the model:

%agent: A(s) %agent: B(s) %init: 100 A(), B()
A(s[./1]),B(s[./1]) @ 1e-3
A(s[1/.]),B(s[1/.]) @ 1e-1
%obs: 'AB' |A(s[1]),B(s[1])|
%mod: alarm 1 [true] do $SNAPSHOT "snap_".[E].".ka" ; repeat [true]

KaSim -i model.ka -l 10 -u time -seed 886009874

Should produce 11 snapshots at events [0;75]. The data.csv file shows time advancing nicely by integers from zero to ten. So far so good. Now, let's continue the simulation (I used the same seed for ticket reproducibility, but it doesn't matter):

KaSim -i model.ka -l 15 -u time -mixture snap_75.ka -o data_2.csv -seed 886009874

Checking the contents of data_2.csv, the time is inconsistent; first data line has the right start time, T=10, but then it somehow resets at the next line has T=1. KaSim has gone back to the past.

As for the snapshots, we have 11 snapshots titled snap_0_0~[d].ka, that all happened at what KaSim thought was E=0, but during the second run, where E should have been advanced (with T) to the state of snap_75, i.e. E=75.

Not only are events not being fast forwarded, but KaSim produced 11 snapshots of identical mixtures in different (wrong) times of the same (wrong) event number (i.e. snap_0_0.ka, snap_0_0~0.ka through snap_0_0~9.ka; they all have the same event number, but different times, and identical mixtures). Other snapshots after the clock caught up produe event name collisions, for example snap_18.ka was produced by the first run, whereas snap_18_18.ka by the second (check their UUIDs).

In a more complicated model, my time went negative, ticking up to zero. My first data.csv goes 0-7107 (point at which KaSim crashed) linearly and monotonically, and then data_2.csv starts at 7099 (time of the last snapshot from the first run), then jumps back in time to T=-6998 (yes, that's a negative time; no I don't understand it, see picture attached), and ticks forward towards zero. KaSim is observing the universe before time, and is therefore a god.

To recap:

1. [E] is not being forwarded as [T] is after -mixture is called
2. [T] is ticking forward to the new T=0, KaSim is not simulating, and yet alarms are getting triggered
3. [T] is forwarded only for initial state, and then ... ignored and reset?
4. [T] can go negative in complicated models with -mixture option

[pirbo]

I've fixed [T] in the data file. I've fixed the alarm trigger between 0 and T0. But indeed [E] is not forwarded as [T] is when -mixture is used. This goes int the bigger problem of "what's the relevance of [E] in a given stochastic simulation"...

[hmedina]

I can see the argument going both ways -update: the user chose to "continue", therefore the event numbering should be monotonic -don't update: it is not a true continuation as the RNG state has been lost, so events are scoped to the UUID effectively

Proposal: There's already an option -initial that (I read as) setting T0 to some value. Have an option that does the same for E0. E.g. -initial_time [float] -initial_event [int] So that -mixture [snapshot] by default updates both, but the user can override that by explicitly setting -initial_time and/or -initial_event