Swarm Bulletin Volume 1, Issue 1

[glen e. p. ropella]

                            Swarm Bulletin
                          Volume 1, Issue 1
                          November 25, 1996


   This is the first edition of the Swarm Bulletin.  From here on out,
the hive will attempt to publish a Bulletin on or before Monday of
each week.  The Bulletin will stand to inform users of the activities
and goals of the hive and user community.  Contributions will also be
accepted to announce Swarm-related events or activities in any of the
growing Swarm colonies around the world.  To contribute, send e-mail
to address@hidden

Table of Contents
-----------------

   I.  Survey Results
       A.  Survey Response Overview (Chris Langton)
       B.  Concatenated Summaries (Glen Ropella)

========================================================================

   I.  Survey Results

       A.  Survey Response Overview

  Thanks to everybody for responding to the Beta-survey!

  We had 30+ responses containing a lot of valuable insight into the
experiences that users have had so far with Swarm.

  As you might expect, the experiences have ranged from very positive
to very negative, with the center of the distribution falling roughly
in the "pretty positive" area. Some areas of Swarm were uniformly
rated worse than others, and the work we need to do to address the
more negative concerns is pretty clearly delineated.

  We'll provide our summary of responses to the survey questions
below, but here I'll give a brief overview of the main lesson we
learned from the survey and what our plans are for addressing them.

  The MAIN LESSON is that, rather than add a lot more functionality to
Swarm, we should focus on completing and documenting the functionality
that is there already. It is clear that with our "inside view" we see
things as being more complete and obvious than they are to others, and
our first order of business is to make sure that what's there already
is clearly documented, illustrated with examples, and works the way we
say it does.

  Therefore, our primary concern for V1.0 - due in January - will be
precisely that; only adding new functionality where it is necessary to
make complete and consistent the functionality that is already there.

The specific areas that need the most work are:



Documentation:

  Clearly, the full functionality of Swarm and many of its features
were not well illustrated or documented. Only Heatbugs was commented
well enough to be a useful application for people to emulate, and
Heatbugs does not illustrate many of the features of Swarm, or provide
any real understanding of why things were done the way they were
done. The other apps (mousetrap and market) were largely useless to
people.

  So, we will be providing a lot more documentation, both on the
overall vision for Swarm functionality in general and on specific
features. This will include bringing the current apps up to the
Heatbugs standard of commenting and explanation, as well as providing
variant ways to do things with each of the apps.  We'll also be adding
a lot more apps that illustrate and flex more of the functionality of
Swarm, and do so in different ways, and in different settings.



Installation:

  Clearly, the installation process was dismal for those people who
had to start from scratch and install all the supporting software such
as gcc, tk/tcl, BLT, and etc. Even having to upgrade these packages to
newer versions was not altogether smooth.

  Several people who responded said it took them weeks to months to
get everything installed.  Others said it was easy. One person even
said he has not installed later versions of Swarm because he's too
scared to talk to his system manager again after his experience
installing it the first time!

  However, once these packages were installed correctly, Swarm
apparently built without problems for most people.

  In the "frustration index" question, many people rated Swarm
separately from the installation process of the other software, and
vented their bad marks on the latter.

  So, a major task for us is to significantly reduce the installation
effort for getting Swarm up and running.

  Configure Scripts with a lot more smarts seem to be the obvious way
to lower the energy-threshold for getting Swarm up and running.  So,
our primary concern for addressing the "installation blues" will be to
significantly reduce the effort and level of expertise needed to get
everything built and running.


Tools:

  The primary concern here was to have better tools for visualizing
the structure of what is built in an app. This includes browsers that
will let one examine the link-structure in the zones, view the
schedules, and provide more user control over execution by being able
to step through schedules, probe objects, and invoke arbitrary
messages on objects. All in all, much better debugging capability and
finer resolution of interaction with running apps was called for.

  We're actually pretty close to being able to provide much of this
functionality, and we clearly need to get it done and documented. Much
of this has had to wait until we complete the Zone support - what is
there now is really just a temporary place-holder that simply provides
a Swarm-like interface to Malloc. Full Zone support will be in place
for V1.0, and this will provide the basis for many of the browser and
interactive tools that users (and we!) need.

  Another tool that is needed is the capability to do batch-runs
(e.g. sweeping parameter spaces) *within* Swarm. Some users have
resorted to external scripts to accomplish this (e.g., the Drone
package from UM), but this functionality can and should be available
within Swarm. We are also close to being able to provide this
capability. Again, it has had to wait on Zones being complete,
particularly the ability to "drop" everything created in a zone by
simply dropping the Zone. This "experiment" mode of managing multiple
model invocations will be included in V1.0, with documentation and
examples.

  Other tools and libs requested included 3-D spaces, continuous
spaces, a more complete Graph library, and the capability to save and
reload the state of a simulation. These are all in the works, to some
degree, and we'll be posting our cut at which of these we can deliver
and when in the near future.


User-Community:

  We need to provide much better mechanisms for users to find out what
other users are doing and how they are doing it. We also need to make
it easier for users to find documentation, examples, and
class-relationship of any and all features/objects they would like to
use.

  This has implications for the documentation itself and its structure
on our web-pages and in the Swarm Manual we're developing.  For
instance, we will be reorganizing our web-pages with an expanded
"User-Community" set of pages. We'll also be restructuring the online
documentation, adding a search-engine, and providing a map showing the
structure of the libs, with links to the appropriate documentation,
examples, and reference pages.

  We again encourage users to provide links to their own Swarm
projects and (hopefully!) to examples of code where they've done
something that they think will help illustrate a useful feature or
solution.

  Also, we're starting to place user-contributed packages up on the
web-pages for people to check out and evaluate. Again. we'd like to
encourage people to contribute back general purpose objects and libs
that they think might be useful to others.

Communication:

  We need to be more aggressive in letting the user-community know
what the SFI Hive is working on and what things can be expected and
when, and we have to deliver what we've promised when we say it will
be delivered. We've dropped the ball on some features that we've
intended to deliver, but which ended up having to wait on other
features that were not there yet. Some users who needed those features
have gotten frustrated enough to give up on us and go-it-alone. This
is a major problem and we have to address it and fix it.

  We'll be posting a weekly "bulletin" on our internal tasks,
including expected delivery dates. These will occasionally include
queries to the community on options and priorities for our work. We'll
also try to do a better job of not promising things unless we are sure
we can deliver them when we said we would.

---------------------------------------------------------------

  All in all, though, we were very pleased with the information that
we gleaned from the survey. Clearly, many people have found Swarm to
be a very useful package - something that they haven't found anywhere
else. It is also clear that there are some obvious areas for
improvement, but people were pretty specific about what those were,
and we have a much clearer picture of what our tasks are in the near
future to address some of the problem areas and fix them.

  Thanks again for taking the time to fill out the survey, and for all
your useful comments and suggestions (and even gripes!)

  Chris Langton
     for the SFI Hive



                              ==========


       B.  Concatenated Summaries

   This is the long awaited compilation of the user survey responses.
A digest of the Survey and answers are provided in

    http://www.santafe.edu/projects/swarm/users/Misc/Survey-responses

But, since this turned out to be quite a long document, we're also
providing you with some digested and massaged summaries of the
responses to each question.

------------------------------------------------------------------------
IA Which platform are you using? (OS and hardware)

   Since the answers varied in accuracy as far as OS and 
chip type, I'll only list the general names for the platforms:

SunOS:           13 users
HPUX:             6 users
Linux:           14 users
IRIX:             1 users

------------------------------------------------------------------------
IB What are the stats of the machines you use? (RAM, CPU speed)

   Again, since the answers varied in accuracy, I'll only present
the average RAM and the average Speed.

Avg RAM:   77 Mb
Avg  HZ:  102 MHz

------------------------------------------------------------------------
IC Which version(s) of swarm have you worked with?

   Number of users having used only 1 version:   9
   Number of users having used      2 versions:  5
   Number of users having used 3 or more:       10

------------------------------------------------------------------------
IIA How did the installation process go? 

   The main focus is on installing the libraries Tcl/Tk, BLT,
libtclobjc, etc.  It seems that the hill is very steep, though,
because there's a sharp contrast between users.  It's either 
considered very difficult or "fairly easy."  And there are a few
comments about how much easier the later installations were.
This either implies that the user has learned more about UNIX
or that the distribution has become easier to install.  The former
is probably more true.

------------------------------------------------------------------------
IIB   How long did it take to install?

   Average amount of time to install everything: 27 hours

   I did this basing a normal "day" of actual work time as 4 hours
(most people don't spend the entire time actually installing, except,
I figured the guy who said "staff weeks" took this into consideration
already and subtracted downtime).  That means 27 hours of actual work
(not waiting for compilers or e-mail responses etc).

------------------------------------------------------------------------
IIC What did you have to do to get swarm to run?

   These were basically just chances to mention the parts of the
installation process that were most difficult.  It seems that the
biggest hurdle is getting gcc upgraded, if necessary.  The other
packages show friction when being installed; but, don't seem to be big
tasks in themselves outside of that friction.

Number that needed to upgrade GCC:                     10
 ""   make, gdb, readline, or libc, or xpm:             7
Number that needed to upgrade(change versions) Tcl/Tk:  8
Number that needed to upgrade(change) BLT:              9
Number that needed to upgrade(change) libtclobjc:      10

------------------------------------------------------------------------
IID If you have built Swarm more than once, how did the later installs
    differ from the first install?

   It seems most people who responded to the survey did not install
Swarm more than once.  Only 10/26 said they'd installed Swarm a second
time.  This seems at odds with the fact that only 8 said they've only
used 1 version.  It seems there should be 15 who'd installed it more
than once.

   In any case, all seemed to think the later installations were much
simpler.

------------------------------------------------------------------------
IIIA   Have the applications worked? What problems have you
encountered with them?

   Comments about the palette, market widget, GA and NN, diffuse
constant in heatbugs, lack of a color monitor, need for flexing apps,
lack of maintenance for old apps, run-time performance problem,
problem with oft-moved windows or if many probes are up on solaris
2.4.  Seems to be common that heatbugs is the only app tried.  This is
worrisome, especially if we want to foster more than just a heatbugs
methodology.
 
------------------------------------------------------------------------
IIIB  Are the applications and their documentation clear? Do the code
      and comments make sense?

   Most people seem to think the comments in the heatbugs app is good.
Most people don't seem to think much of our other doc attempts.  This
may well increase the priority of a Swarm Manual proper (i.e. not just
the postscript or html piecemeal docs).

   Two interesting comments were made: 1. that it was not obvious
where to look for explanations of the modelswarm and observerswarm
windows that came up and 2. not being able to glean much from the
other apps.  The former implies that the Swarm "probe philosophy"
isn't clear.  The latter implies that the the way heatbugs is
commented should be the norm, not the exception.

------------------------------------------------------------------------
IIIC  Was it clear what the applications were trying to illustrate?

   12 "yeses" with no useful info at all!  Says something about how
well the question was formed, eh?  Anyway, we got two comments
pejorative of market and one that claims it's straightforward.  This
implies that it may not be clear where market came from and why we
include it.

   One comment implied that mousetrap is not well-defined.  Something
more should be said about it (like commenting it as extensively as 
heatbugs).

------------------------------------------------------------------------
IIID Do the applications show the generality and applicability of the
     Swarm kernel or do the details of each app obscure it?

   The comments that say the apps *do* demonstrate the full
functionality of the kernel do not inspire faith that the full
functionality is realized.  This is in part because two power users
make the comment that the full functionality of the kernel is not
flexed by the apps, whereas others claim it is.  This just puts
emphasis on the fact that we don't really show the full capabilities
in the apps or docs.  It also gives evidence that schedules aren't
used in novel enough ways.

   Interesting comment about reuse that leads into the issues of a
schedule language and discussion of templates, macros, and forms.

   Mention of too much concentration on heatbugs.  We need another
"Power-App" that does things in a different way to compete with the
influence of heatbugs.  This could be Turmites or, possibly, Barry's
Autopoiesis model.

------------------------------------------------------------------------
IVA1 please give a brief description of what you're modeling and how.

   Lots of good examples.  We will need to pursue web page links and
source code for as many of these as is reasonable.  This also begs
for discipline slicing of the user community, where social insect
modelers get together, manufacturing simulators get together,
ecologists get together, etc.  Part of this will begin at the 
SwarmFest.

------------------------------------------------------------------------
IVA2 Are they significantly different from any of the supplied
     applications?

   About 10 users claim significant difference from the demo apps.  We
can probably say that at least 6 are truly different: float space,
multiple agent types, death and birth, lattice, higher than 2d, heavy
batch mode use.  (We won't know actually how different they are unless
we see source code.)  We could probably use these to enhance our demo
apps to show a broader range of kernel functionality, even if we don't
try to distribute the entire application the user is working on.  The
range of things these users are considering "significant" differences
still do not really push the envelope.  Somehow, we need to show as
much novel functionality as possible.  We could do this with rivals to
heatbugs and with a user entry doc that targets the concept space
Swarm is trying to address.

------------------------------------------------------------------------
IVA3 Are you re-implementing a model already running in another
     system?  (either off-the-shelf or specialty code)

   Didn't get much from this question.  DEVS-Scheme and ModSAF were
mentioned.  Responses confirm that most work is done with home-grown
code and at least one person mentioned that Swarm helped develop a
more satisfying formalism for their model.  Both of these type of
comments show the need for something like Swarm.

   One comparison mentions the impact of high overhead associated with
message passing.  This will need to be addressed after v1.0.

------------------------------------------------------------------------
IVA4 Are there any abstracted or generalized principles you've
     developed for implementing your model(s) in Swarm or other
     systems that are either enhanced or impeded by the way Swarm is
     designed?

   The answers to this question seem to point in the general direction
that Swarm is a good scientific tool.  Positive comments like:
productivity escalation, the ability to focus on an abstract UI,
convenience of the libraries, and flexibility give evidence to this.
Even the negative comments: lack of batch processing capabilities and
the apparently opaque schedule logic show a focus on *real* issues in
science and simulation.

   The negatives listed definitely put hard pressure on batch
processing (and all its relatives: the RNG, experiment Swarm, Zones,
etc) and aggressive documentation.

------------------------------------------------------------------------
IVA5  Do you think Swarm can or will make it easier to communicate and
compare your model and your results to others in your field?

   The response to this was mostly positive.  One mention of language
choice, which is relevant for interfacing with Swarm; but, not with
this particular question.  A couple mentioned the difficulty of
installation and ease of use issue.  But, most think that the answer
to this question depends only on how much Swarm gets used, which is
not the focus of the question.  It seems more emphasis is needed on
the purpose of Swarm as a tool to help focus on model building instead
of implementation building.  The user entry doc should help so that as
users are introduced to Swarm and begin to learn it, they keep the
Vision in the back of their mind.

------------------------------------------------------------------------
IVB What problems have you had in building your own apps?

   Lack of good documentation seems to be the reigning complaint here.
Another notch up in priority for the Swarm Manual and docs.

------------------------------------------------------------------------
VD Given that the libraries are still fairly incomplete or even
   nonexistent, what feature(s) do you consider of highest priority to
   be added (or improved) in the near future? (e.g. 3D space, graph
   lib, etc.)

   Interesting Java user interface "hook" idea that has implications
to uniformity in the control of Swarms.  Otherwise, nothing new here.
The number of responses to 3d space (and visualization) might bump
priority on that up.  Most of the others are already on the list
of tasks: bitmapped symbols, graph library, float space, data-flow
methods, random library, and parallelism (post v1.0).

------------------------------------------------------------------------
VE  What support tools would you most like to see added soon?  (e.g.
    editors, browsers, visualization, debugging, etc.)


   Interesting comment about code structure visualization, which I
take to mean data-flow, call-graph, type things.  This type of
visualization will be taken care of by the Zone browser, which should
be an extension to probes.  Debugging is definitely a priority and any
development on data visualization for the spaces and outputs is
important.  Schedule and collections browsers and editors are present
in the task space already.

------------------------------------------------------------------------
VF What types of systems would you like to see interfaced to swarm?

   Lots of refs to GIS and Mathematica.  We could worry about pipes
later.  But, we would buy alot of analysis and visualization tools
with an Xface to Mathematica (or Octave, which is a free MatLab
clone).  Plus, the data-flow paradigm data passing both internal
to Swarm (via probes) and external to Swarm needs some discussion.
Doing this uniformly across all of Swarm will buy consistency and
understandability.  GRASS integration is already in the task space.

------------------------------------------------------------------------
VG What other simulation packages or frameworks have you used and how
   do they differ from Swarm?

   Each one of these packages should be explored for either a
competitive stance to Swarm or as a possible complementary role.  This
will be added as an ongoing duty of the hive.

------------------------------------------------------------------------
VIA   How many people at your site are using Swarm?

2, 1, 1, 1, 1, 1, 1, 1, 2-3, 2, 1, 1, 1, 3, 4, 1, 2, 1, 
1, 1, 5-10, 3, 1, 2, 6

=> 46   total
   1.84 per site (more likely dept.)

A couple of people said they're likely to recruit others to join their
colony.

------------------------------------------------------------------------
VIB Do you know anybody who tried to use swarm but quit or would like
    to use Swarm but can't for some reason?

   There were a couple of good hints; but, mostly, the installation
hurdle takes the cake.  And this is understandable for beta test
phase, but is inexcusable for v1.0.  One comment was made that the
language is an obstacle, which argues for more convenience objects;
but, it's likely that unwillingness to learn a new language will
transfer onto any new platform.  Effort towards a schedule editor and
zone browser will reduce the occurance of this.

   There was one performance-related comment.  But, given the 
generality of Swarm, this is expected to be true until we have
implemented a parallel version (after v1.0).

------------------------------------------------------------------------
VIC We are planning a User Meeting sometime in February '97 where
    users will be able demonstrate their models and compare notes with
    other users.  Are there any other ways that you think would help
    foster communication between the various users of Swarm?

   Some good ideas here are: Swarm team regularly posting, published
ToDo list, and fostering collaborative efforts.  All of these will
be attempted in various ways.

------------------------------------------------------------------------
VID Up to this point, the Swarm Project has tried to develop a
    "grass-roots" or bottom-up approach to the development of Swarm in
    order to encourage a user-driven growth pattern.  How do you think
    the user/developer relationship should be handled in the future?

   Significant comment that documentation and development of the user
community is more important than library and tool addition.  This is
emphasized by code contributions and easy access to names and projects
of others.  This also emphasizes the desire for industry/discipline
cuts.  Maybe we could have sections of the User pages that addressed
different disciplines?  

------------------------------------------------------------------------
VIE How is the swarm-support mailing list?  Is it meeting the users'
    needs?  Should it be split into an "installation/maintenance" list
    and a "model/design" list?

   There seems to be a heavy split between people who would like to
split the list and people who don't think it's reasonable yet.  Also,
it seems reasonable to establish a method of distinguishing the
various types of posts to the lists.  I've seen several lists that
have methods for doing things like that.  We might have subject line
keywords like INSTALL, OBJC, METHOD, or somesuch.  And we could even
have a discipline cut with headings like BIO, COMPSCI, etc.  But, for
now, we should leave it alone until traffic becomes too heavy.

------------------------------------------------------------------------
VIF How should user contributions of library and tool objects be
    handled?  Should a type of "peer review" and validation be
    implemented via, for example, submissions to swarm-support?

   Given what Manor's going through with the RNG code, I think it may
take too much effort to Swarm-ize all users' code.  Not to mention
that this is too heavily reliant on the opinions of the code
evaluator, which is *not* a "grass-roots" approach.  But, supplying a
place to make it available and having a division between
"kindatrusted" and "nottrusted" contributions is a good compromise.
And those pieces that we want to fold into the kernel or are very
closely tied to kernel functionality should be stringently examined.
There should be guidelines for this available to the users.

------------------------------------------------------------------------
VIG1 Is it acceptable to place all user contributions of libraries and
     tools under the terms of the LGPL?

   The point is made here that it should be possible to contribute
code you copyrighted to yourself and with restricted use.  However,
any libraries that Swarm will depend on will *have* to be LGPLed.
I.e. we have to provide a way that companies can both make money
*and* contribute back to Swarm.  We have a couple examples on our
ftp site of contributed code under the LGPL but copyrighted to 
the contributing institution.  Some guideline should be available
for this, also.

------------------------------------------------------------------------
VIG2 What do you think of the way Swarm is distributed and released?
     Do you have any suggestions on how it should be distributed in
     the future?

   Most responses were ok with our present distribution scheme.
But, there's clearly a live worry about Web reliability, the size
of the distribution, incremental releases, and separate module or
library releases.  All of these will be considered when we develop
a more permanent distribution scheme for v1.0.

------------------------------------------------------------------------
VII1A  Do you have any suggestions on how the web pages should look?

   We received a ping for an online tutorial, which will be a
possibility; but, the manpower might not be present until later.  We
were also pinged for postscript docs, which are underway as our SGML
efforts continue and might be obviated by the Swarm Manual, proper.
There's a comment praising simple pages with few bells and whistles,
which is good because we can't afford to spend a bunch of time on that
anyway.  There was also a comment about starting a user list, which
will be addressed by the user community page.

------------------------------------------------------------------------
VII1B (1,2,3) We are planning to have a spot on our web pages that
      will cross- reference as many users of Swarm as possible.

         1) Would you mind if we published your introduction as posted
            (or to be posted) to the swarm-support mailing list on our
            web page?

         2) Do you have descriptions of your models and references
            already on the web that we could link to?

         3) If you have papers or models would you mind if we included
            them on our web pages?

   Most people reacted quite positively to this, except most don't
have anything to link to *yet*.  We will pursue these links as avidly
as is reasonable.

------------------------------------------------------------------------
VII2  On a scale of 1-10, list your frustration index: 
      (0 = not at all frustrated, 10 = threw it out the window and
      don't intend to ever talk to you folks again....)

   Several people listed two indices, one for installation and one for
use.  So, the numbers were split and averaged as such.  Where there
was only one number, the same number was used for both.  It's a very
good sign that even though installation is our major hurdle, once it's
been leapt, the memory fades quickly!

Avg Installation => 4.47
Avg Use          => 3.45
------------------------------------------------------------------------
VIII  Please make any additional comments or suggestions,

   All the comments are appreciated.  Several reiterated the fact
that one must still be a technical person to get Swarm working.  And
one person again recommended a Java port.  Most of these comments were
positive and give a warm fuzzy about Swarm.
------------------------------------------------------------------------


                              =========

The Swarm Bulletin is created by the members of the Swarm project at
the Santa Fe Institute.  Comments, corrections, and contributions
should be sent to address@hidden

November 25, 1996