Re: Q: ActivityGroup Class & Land Uses

[Kevin S. Lim]

Marcus and Benedikt,

Many thanks for the clarifications... I've found the little stinkin bug...
apparently, when a land use gets set to a code, it sets a flag to false
thereby identifying it to be unavailable for use.  What was happening was
when a patch of land was coming out of fallow (i.e. getting set to a stage
of secondary succession), the flag was getting set to false because of the
method, thereby explaining the 1 time event lag.  The secondary succession
patch wasn't getting set back to available for use until the next time event
when the code is checked in a switch control structure.  It's always the
little things, right!! hehe =)

About dynamic scheduling... I completely agree, *but* because my ABM
comprises both an ecological and human sub-model, I decided to steer away
from that type of scheduling to ensure that I could "watch" and understand
what was happening first.  For instance, I don't want a part of the
ecological model dynamically scheduling some action that in combination with
a dynamically scheduled human action, results in some of emergence that I
can't trace back easily.  From my readings, my integrated ABM will be one of
the first with complex feedback loops between both sub-models with a dynamic
micro-economic model sitting on top of both sub-models.  So for now I
decided to go with simple repeated scheduling -- although this will most
likely change in the future.

Catch ya later at Swarmfest2000!

Cheers,
- Kevin

Kevin S. Lim - B.Sc.(Env) - MES Candidate
Department of Geography - University of Waterloo
www.fes.uwaterloo.ca/u/klim  ICQ#52585289

----- Original Message -----
From: Benedikt Stefansson <address@hidden>
To: <address@hidden>
Sent: Wednesday, November 24, 1999 6:17 PM
Subject: Re: Q: ActivityGroup Class & Land Uses


> Kevin,
>
> Marcus already covered some of these points while I was writing the
message,
> however in the interest of verbiage...
>
> The best way to think about activity groups, schedules and activity is to
think
> of them as nested ordered lists. After you define each action group and
events
> on schedules and 'activate' the schedules activity groups are merged into
> schedules and schedules into the activity in effect by constructing one
large
> list (the aggregate schedule so to speak).
>
> In the present configuration of Swarm the order in which events are
defined and
> schedules activated  in your code determines how methods will be called in
the
> program. I.e. first event in the first activity group on the first
schedule to
> be activated is executed first etc (this was a recent topic of discussing
> w.r.t. to ObserverSwarm/ModelSwarm and when GUI is updated).
>
> I think your example would be a prime candidate for doing away with
repeated
> schedules and scheduling all events dynamically. A plot that gets seeded
with a
> crop sends a message to schedule N growth events in sequence. When the
plot
> goes fallow at the end of the growing period it schedules a new sequence
of
> growth after M periods in the future etc. In the long run this might allow
you
> to experiment with more heterogeneity in the event structure.
>
> I learned a lot about the pitfalls of Swarm scheduling by writing two
examples,
> included here . One is a silly little example, based on the simpleBug
tutorial,
> where food is regrown in the lattice as bugs eat it up. Food growth is
> rescheduled for each lattice location when a bug gobbles up the square.
There
> is a tiny bit of documentation there in the form of an html file.
>
> The canonical dynamic schedule demo is of course mousetrap.
>
> The app in the other tarball shows colored blocks on a raster to give
visual
> feedback as to when events are executed, using different types of
'repeated
> scheduling' as it were. Compile and then single step with 'next' in the
control
> panel. It might be a suitable template for a workbench if you need to
debug
> some scheduling problems.
>
> Benedikt
>
>



                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================