Feature request: continue mode

[hmedina]

It would be useful if KaSim had the option of a "continue" mode that could be launched with a snapshot and the inputs file (optionally the traces file).

Here's the scenario: I simulate for a large amount of time, but then have to stop (because of power outage, or because I'm changing from laptop to server, or even I ran out of interactive ideas). I can dump the mixture to a snapshot, and I have input.ka with the seed and ruleset. Then, I could tell KaSim to simulate input.ka, starting from the snapshot, fast-forwarding the time to the snapshot's time (recorded in input.ka), with the same seed (also recorded in input.ka), and just append to the output file (also recorded in input.ka). That way I would have a single data.csv, with plot points in compatible times.

The key features would be:
-Append (rather than overwrite) the trajectories file
-Ignore %inits: in inputs.ka and use the snapshot instead
-Fast-forward time to the snapshot's time

[pirbo]

• I've just pushed the second item.
• Third item is "easy".
• First one is probably doable.
• Append to the trace would very painful.
• the seed part is simply impossible. There is no other way to regenerate the state of a random number generator after k calls than to know k to reinit a random name generator with the seed and to make k calls !

Continued simulation will be unreproducible... So, is it worth it?

[pirbo]

Third item done but I've just realised one more issue:
if you stop in the middle of a flux map computation, no way to continue it

[hmedina]

I see two use-case scenarios for this mode:

1. User wants to salvage a trace after the server crashed
2. User decides post-facto to extend a simulation

In scenario 2, the program terminates properly. Couldn't it print to the trace file the current state of the RNG? That would allow continue to start where it ought to.

In scenario 1, the program did not terminate properly. The only way to salvage this trace would be for every event to also log the RNG state.

How costly are these options, log the RNG state on the trace upon exit, or at every event?

[hmedina]

Would it be feasible to have the following behavior:
At simulation's end, if RNG state is requested (e.g. by the trace option), dump the state in a format (opaque binary is fine as far as I can think of).

Then, if selecting continue mode, KaSim tries to read the correct RNG state file. If found (e.g. it matches the UUID of the trace), it continues from there and appends to the trace file. If it can't find it, it asks the user if (s)he wants to regenerate the RNG, and if yes proceeds to hammer the RNG for its kth state (k would have been defined in the trace, the seed in the inputs.ka file) to re-obtain the RNG state at the end of the trace it has. It would then continue the simulation from there and append to the trace.

This behavior would allow the user to recover from scenario 1 (costly as it is), and continue from scenario 2 (with minimal cost).

[hmedina]

Now, what's the interaction between batch and continue ? It seems logical to assume that a user could want both batch and continue, as well as interactive and continue. Would continue be an additional & different flag to the command line? If so, would batch+continue have as a default to regenerate the RNG state if state-file not found?

[hmedina]

I see the trace file contains all the contents of the model. It seems that one could continue from a trace without the inputs file.