6.6 Persistent Storage

Document: SCL: An Artificial Chemistry in Swarm

6.6 Persistent Storage

An essential part of the requirement for SCL was to support persistent storage of a model--i.e. being able to save a model into a disk file, and reload it later. This is not supported by any of the current Swarm example applications, and there is little support for it built into Swarm.

Swarm does provide object classes ObjectSaver and ObjectLoader intended to take an arbitrary object and save it or reload it. I experimented with these, but eventually found them too cumbersome. They operate by exploiting the Swarm probe machinery. Thus, in order to control exactly what instance variables are processed, it is necessary to establish appropriate probeMaps. Further it is difficult to use these methods in a way which easily respects the class inheritance hierarchy. Finally, in some cases, instance variables cannot be meaningfully saved to disk in their normal form--because they are actually pointers, and the same object will not generally be guaranteed to be at the same location when the model is reloaded (indeed, it would generally be highly unlikely). In these cases it is necessary to ``re-code'' these variables in some sense. To do this within the ObjectSaver and ObjectLoader framework would mean developing special ``proxy'' objects, to which ObjectSaver and ObjectLoader could be applied, but which would contain the ``re-coded'' instance variables. Given all these complications, I abandoned this approach.

The strategy I adopted was to provide all relevant objects with methods, saveTo: and loadFrom:, which will save to or load from a given disk file (implemented as a Swarm OutFile or InFile object as appropriate). The sclModelSwarm then provides methods to get a file name, open the file, and invoke the required saveTo: and loadFrom: methods, in order, on all required objects. This finally worked satisfactorily, but there were various problems along the way:

The InFile and OutFile classes did not include methods for all native types--specifically, unsigned and BOOL. These were saved in int form instead, but this is not robust and obscures the code.
The saving and loading methods are not symmetrical; it is necessary to write extra white space to guarantee correct reading.
InFile and OutFile do not record the types of the fields being stored, which makes it harder to detect mismatches between the saving and loading processes.
The WorldRaster class has a bug, such that, when dropped, it does not automatically cause the corresponding widget to be dropped.
To guarantee following exactly the same trajectory after reloading a model, it is necessary to store (and reload) the state of the underlying random number generator. This is not directly possibly with the standard Swarm generator. This is discussed in more detail in the next section.
Similarly, to guarantee following the same trajectory on reloading, it is necessary that the ordering of the agent lists be preserved. This is somewhat tricky. It means, in particular, that the SCL model must not be saved simply by scanning the 2D space, and saving the particles in that order; rather it must be done by scanning the agent lists, and saving in that order instead.
There is still an issue of how, exactly, to ``recode'' pointer information. In SCL the only significant case of this was the pointers from bond agents to L agents and vice versa. The solution in this case was simply to recode the pointers to L agents by their world co-ordinates. The pointers could then be reconstructed on reload (provided, of course, that the L particles are reloaded, without any bond information, prior to the bonds). The reverse pointers, from L particles to bonds, can also then be re-constructed as the forward pointers are re-established.
There is a significant issue of what, if any, state information is hidden in the Swarm scheduling and activity machinery. There is no built-in support for accessing this. In the case of SCL, which does not make use of any advanced features of this machinery, I finessed this problem by having the only activity be to execute the step method on sclModelSwarm. This object (and method) are not changed by saving and/or reloading; this variation is all hidden in other SCL objects, which the activity machinery is not aware of. One small side effect of this is that the ``model time'' cannot be taken from the Swarm activity system (as it continues to increase monotonically, regardless of saving and loading operations). Instead, the worldManager simply keeps its own independent record of model time, which is saved and/or reloaded as necessary.

6.7 Access to Random State?

6 SCL Design Notes

6.5 Agent Update Order

Document: SCL: An Artificial Chemistry in Swarm

mcmullin@eeng.dcu.ie