Re: Sub-swarms

[Alex Lancaster]

Ken and Paul,

>>>>> "KC" == Ken Cline <address@hidden> writes:

KC> Paul,

KC> I do vaguely remember this, and no, I don't think my advice works.
KC> I didn't try implementing the reset functionality as I described
KC> below but I did try something similar.  After several days of
KC> countless failures I shelved to work as extra functionality to
KC> completed at some later date (ie catagory: "Bell or Whistle").

KC> As I recall, I could never get the schedules/activities to die
KC> quietly; I have a nack for making them core dump :).=20 Anyway, in
KC> Sept. we started work on a different model and implementing a
KC> reset hasn't been an issue yet (ie runs are typically done in
KC> batchmode, with multi-run "studies" setup with a Java applet, ala
KC> Drone).

This shouldn't be a problem if your modelSwarms are completely wrapped
up in the usual way and you kill the activity *before* dropping the
Swarm itself.  Have you had a chance to look at "simpleExperBug" in
the tutorial apps that Chris wrote early last year?

This provides a good working base to build similar applications
yourself.  What this application does is to do each "run" of the
experiment essentially in batch mode, but controlled by a overall
GUISwarm, which manages the parameter space.

The basic trick to making the model drops work is to build your model
Swarm in the usual way :

  [modelSwarm buildObjects];
  [modelSwarm buildActions];
  [modelSwarm activateIn: nil];

but, note that you activate the modelSwarm in "nil", which means that
you can later activate in this activity in another scheduled
method. When it comes time to "drop" the Swarm, first, simply drop any
GUI objects - because this requires interface to the GUI, which is
independent of the Zone allocation mechanism - associated with the
modelSwarm (if the modelSwarm is running in pure batch, obviously this
won't be necessary). 

Lastly, call "drop" on the modelSwarm, which should drop all the
objects built by that Swarm - provided, of course, that everything has
been allocated through the Swarm Zone mechanisms (i.e. no rogue
malloc's!)

  [probeDisplayManager dropProbeDisplaysFor: modelSwarm];
  [[modelSwarm getActivity] drop];
  [modelSwarm drop];

It repays to study this app carefully.  There are a number of features
in the currently available distributions of tutorial which I am
working at to update.  Most specifically, is using the Swarm itself as
the basis of all memory allocation within itself, which is a design
feature of Swarm, but some of our demo apps and tutorials haven't yet
been updated to reflect it.  In other words, instead of writing:

 modelZone = [Zone create: [self getZone]];
 modelSwarm = [ModelSwarm create: modelZone];

you simply write:

 modelSwarm = [ModelSwarm create: self];

and the Swarm handles the creation of a new Zone internally. This
results in much neater and less cluttered code.  All objects (only
within in a Swarm!) can also be created in the same way:

 bugList = [List create: self];

The current version of simpleExperBug *doesn't* use this feature as
yet, but the next release will.

I am also adding a new tutorial example "simpleExperBug2" in the next
release which will be an extension of the batch mode, to a more
general GUI and batch mode "Experiment Swarm", in which at each "run"
of the the experiment, the user can choose to either have the full
ObserverSwarm/ModelSwarm breakdown running as a sub-Swarm or just have
it run the modelSwarm sans GUI.

This will be quite useful if you are using something like a GA to run
your experiment, in which in the early generations you don't have
anything very interesting to "look" at - but in later runs you may.

With something like a proper experiment manager you can essentially
"fast forward" through the experiment runs in batch mode, and then
dive into full the GUI version to do your "probing" and and tweaking
manually when you have some interesting behaviour to look at. You also
really want to be able to do this without leaving the environment of
the experimentSwarm.

I am experimenting on using this approach in one of my own apps, so if
anyone wants to contact me outside the mailing list to exchange code
or discuss ideas, feel free do so.  I am also using J.J.'s "Breeder"
the GA library as a basis for the manager, I am really trying to push
the Swarm envelope and re-usability as much as possible.  I believe
that a good general purpose experiment manager "library" is vital to
Swarm, and definitely needs more attention.

>  - ObserverSwarm's are (usually) a subclass of GUISwarm
>       and, as such, have a control panel.  You may or
>       may not want more than one control panel.
> 
>  - If you do want a control panel for each "run" inside
>       the simulation then you may have to create a new
>       type of control panel.  For example, if you click
>       `quit' on any control panel I *think* this will
>       end the whole simulation.

No, this is not necessarily true.  If you build a whole new GUISwarm
*within* a GUISwarm, the new actionCache (not controlPanel) *will*
function independently from the top level actionCache.  The whole
notion of actionCache/controlPanel is in the process of being
redesigned to accommodate a more general purpose way of interacting
with Swarms that does not depend on a GUI being present.  See some of
Glens' earlier postings on the list on this issue.  Unfortunately the
implementation is only 60% of the way there at the moment.
 
>  - You might consider having only one ObserverSwarm and
>       just creating a new ModelSwarm for each "run".

This is the way that "simpleExperBug" currently does it.

  --- Alex

-- 
  Alex Lancaster         |   e-mail: address@hidden
  Swarm Developer        |      web: http://www.santafe.edu/~alex
  Santa Fe Institute     |      tel: +1-(505) 984-8800 (ext 242)
------------------------------------------------------------------

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================