Re: [Swarm-Modelling] Some Questions regarding SWARM M&S

[gepr]

Sunwoo Park writes:
 > I) What kind of simulation does SWARM offer ?
 > Discrete-time or discrete-event simulation ?  Or, ... ?
 > It is still not clear for me how SWARM maintains simulation time.
 > Does SWARM actually advance simulation time based on a certain time
 > management scheme (e.g., conservative, optimistic, risk-free, etc.) or just
 > simply increase a "time counter" ?
 > As my understanding, so far, SWARM looks like a system (or infrastructure),
 > rather than simulation framework, that permits creating, experimenting,
 > observing, and analyzing complex systems based on agents' behavior or
 > collaboration. The meaning of simulation in SWARM is agents' behavioral
 > evolution (or adaptation) to their environment over time ?

Your evaluation of Swarm is correct.  It's not so much a platform 
for building simulations as it is a grab bag of miscellaneous tools
(functions, libraries, macros, classes, protocols, etc) that you can
choose to use or not.

The only thing that makes Swarm appear as if it's a platform is the
fact that we could never coerce it into separate pieces that could be
invoked separately.  Originally, Roger, Chris, and Nelson had the idea
to make it a looser collection of libraries that were separately
invokable and linkable.  But, there's always a tug-of-war between
those users who want the swiss army knife and those who want a whole
box of tools.  And Swarm wended its way into a not-so-well-integrated
swiss army knife.

Now, the more precise question you're asking is:  Is the Activity 
library discrete-event or discrete-time?  And "What implications 
fall out from the way the Activity library handles time?"  Or
"What does time mean with respect to the Activity library?"  Oddly
enough, I just had an argument with Roger about this the other day.
Since he wrote it, I'll go with what I presume would be his answer:
It's discrete-event.

The Activity library simply gathers together, organizes, and executes
singleton events (as Steve points out).  There is no "time" per se,
other than some misnamed protocols like RelativeTime.  Any given
activity structure is a partially ordered set of events.  That partial
order can be tracked (indexed) with a monotonically increasing
parameter, which, in this case, is an integer... which some people
call "time".

Any activity structure can be modified or built on the fly.  And if,
at "time" 2, you add an event at "time" 600, and there are no events
between "time" 2 and 600, then the events at 600 will happen
immediately after those at 2.

As for the higher level reasoning over schedules (conservatism,
optimism, etc.) , I don't think Roger or Vladimir ever got around to
putting any of that fancy stuff in.  We used to talk alot about a
"scheduling language" where the activity api would be filled out
enough to do interesting things like do loops, if branches, etc.  But,
we never did the work.  At one time, I tried to put some intelligence
into the ActivityControl; but, that's about when I left the SFI and
everyone that looked at it after me just seemed to be confused by what
I did (or thought it was stupid ;-).

 > II) In the perspective of simulation modeling,
 > So far, SWARM modeling looks like "programming" rather than "simulation
 > modeling". So, I'm wondering how SWARM model can (1) represent state
 > transition, (2) keep time information regarding its dynamic internal states
 > (e.g., state holding time), (3) consume/produce events with simulation time
 > adjustment and/or dynamic state transition, (4) handle Input/Output event
 > conflict (e.g., when event consumption and event production occur at the
 > same time), etc. in generic (or formal) way ? Is there any activity
 > regarding SWARM agent modeling based on specific formalism(s) (or
 > mathematical modeling) in SWARM community ?

There's a heuristic that we followed: Anything a human can manipulate
should be manipulable by a piece of software and vice versa.  What
this turned into (regardless of what the intentions were) was that the
_code_ is the model.  If abstraction (likewise with concretization)
was committed, then attempts were made to automate that abstraction.
If the abstraction couldn't be automated, then it was weakened to the
point where it could be automated (like in the space and objectbase
libraries) or it was left out.

What this results in is really a programming library, not a simulation
environment.

Now, there are arguments on both sides of whether this is a good thing
or a bad thing.  But in the end, since it's just another tool, no
value judgement should be made.  You either use the tool or you don't.
However, something should be said about when the tool is effective and
when it's not.

All of the issues you mention (1-4) are high-level concepts that
require some assumptions to be made before you can talk unambiguously
about them.  For example, (1) representing state transitions.  Since
Swarm is based on Objective-C and Objective-C covers C, and it's all
compiled with GCC, state management is based on that tool chain.  You
can use Swarm constructs (like zones and actions) to keep track of
state.  You can use Objective-C constructs (classes, objects, and
messages).  You can use C structures.  Etc.

The thing that makes Swarm a bit different from other tools is that
_no_ attempt was ever made to wall off the functionality of the layers
underneath it (because "anything a piece of software can manipulate
should be manipulable by a human").  So, if a zone, for example, can
allocate 4 bytes of memory, then a human ought to have a button or
somesuch that will allow her to allocate 4 bytes of memory.

(Now, when I say "no attempt", I'm lying a bit... some things were
walled off because people get "wild hairs" at times --
e.g. Objective-C's "copy" versus Swarm's "copy" ... you can find a
list of some of these in the source code in defobj.)

So, when doing "simulation and modeling" in the same way you'd do it
with, say, Arena, Simscript, PowerSim, or any of those tools, you have
to _build_in_ the chain of assumptions you want to hold true.... just
like programming.  A simple example of this would be Nelson's "sugar
scape in swarm" model.

[grin] So, why in hell did we do things that way?  I'm so glad you
asked.  But, I'm going to take a break and go back to work and if
nobody picks up the thread, then sometime in the next few days, I'll
continue.

-- 
glen e. p. ropella              =><=                           Hail Eris!
H: 503.630.4505                              http://www.ropella.net/~gepr
M: 971.219.3846                               http://www.tempusdictum.com