Re: Instantiating multiple ModelSwarms

[Marcus G. Daniels]

>>>>> "FW" == Fred Wan <address@hidden> writes:

FW> My first question is: what difference in effect have the arguments
FW> "this" (SimpleObserverBug2) and "null" (SimpleExperSwarm)?

The argument to activateIn is the time sequence that the Schedule or
Swarm will be merged-into.  (It's another Swarm.)  If it is null,
that means that there are no other peers running along with it and
thus is not temporally correlated with anything else in a simulation.

If the argument was a Swarm representing a company, the object on
which activateIn was called might be an employee in the company.  The
employee might have a schedule for their personal work day schedule
and the company might (only) have automated processes for physical
infrastructure.  Note the company is not really `running' until some
employees are running, even if those employees are to some extent
independent agents.

The activateIn (null) feature is attractive for running parameter
sweeps since these runs can be thought of as concurrent processes.
Unfortunately, Swarm doesn't currently have features for exploiting
concurrency.  I'd say the ExperimentSwarm is worthwhile if you have
particularly complicated experiment you want to run (e.g. computed
perturbations based on the simulation dynamics).  For simple parameter
sweeps, command line arguments are easier to deal-with just because 
there are less ways to mess up, and because you can use rsh/ssh to
spawn multiple runs in parallel (given multiple computers or an SMP machine).

FW> In runModel the modelSwarm is activated with:

FW>     modelSwarm.getActivity().run();

When activateIn is called on a Swarm or Schedule, an Activity is
created.  An Activity contains the index that steps through the all
the Schedules & Swarms that are running.  The activity like a program
counter on a CPU, but for this hierarchical discrete event scheduler...

FW> This is somehow needed to activate the modelSwarm but again it is
FW> different with the way in which it is done in
FW> SimpleObserverBug2. What exactly is the difference?

GUISwarm's `go' method coordinates Activities with the Control Panel.
That's the only significant difference.

FW> The general question is now how to do this, i.e., how to add the
FW> display objects (of SimpleObserverSwarm etc.) to ExperSwarm. Is
FW> there an extra Swarm in between necessary perhaps? The control
FW> scheme would then become: ExperSwarm -> ObserverSwarm ->
FW> ModelSwarm

W.r.t. Java, GUISwarm is important for two reasons: 1) it provides the
ControlPanel management, and 2) it contains a reference to ActionCache
which is the only way without extra JNI code to run doTkEvents.  You
need the latter call periodically to make all the GUI widgets update.
I can't see any reason why your ExperimentSwarm couldn't be a
GUISwarm, though.

                  ==================================
   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.