Re: ObjectLoader & batch processing

[rmb]

>    Well, on to the next question: do you see it as a reasonable thing to do 
>    (or even a possible thing to do) to allow the Swarm app to execute a 
>    number of runs itself (resetting simTime to 0, killing and re-generating 
>    swarms & objects, etc between runs)
> 
> Roger might have some guidelines on this... This seems quite difficult.

Generating new swarms and objects to rerun from time zero are all fairly
straightforward in principle, so long as you've coded your model and observer
swarms (or whatever structure you have) to start themselves cleanly each time.
But there's no support in the current control panel to do this, and it's also
not feasible right now (though admittedly quite reasonable) to expect all the
resources allocated each time to be fully released, so that this cycle could
actually be performed more than a few or a few dozen times before the overall
Unix process bogs down hopelessly.  That's why Ted Belding's approach of
starting each run with parameter settings in a new Unix process is the most
feasible for now.  Whether the parameter settings are set from a file or the
command line doesn't matter, just that a new process is started.

Releasing resources when dropping old swarms and restarting them isn't in
that bad a shape, and will gradually be cleaned up in further releases.  But
the model itself must coooperate in freeing any resources it allocates, and
that's something we hope to build in some standard support for.  We're also
chasing down a few possible memory leaks.  So, restarting an entire Swarm
model in the same Unix process, without fragmenting memory or causing other
cumulative effects, is something that's very much within the direction of
Swarm, but for the time being, Ted Belding's approach of separate program
runs is the most practical to actually run experiments or sweep parameter
spaces.

Roger