Re: Modelling time passing

[Roger M. Burkhart]

> This might be too obvious a modelling problem, but it's something I'm
> running into.  I have several agents (of course) and want to model them
> working asynchronously.  I had a parallel version in which the asynchrony
> happened automatically, since the agents ran at different speeds and so the
> messages they sent each other happened at various times.

It sounds like you must have been getting a lot of inherent variability
as a result of the underlying machine, but in Swarm the preferred practice
would be to use an explicit random number source for any variability so that
your results could be exactly repeatable.

> What's the natural swarmy way to model this?  I'm starting them from a
> schedule and having them schedule future work for themselves and each
> other, but the execution of an agent appears to happen in zero time from
> the point of view of the schedule, so all the future work is scheduled for
> the same point in the future. What I want is for the agent to work, and to
> have the schedule to appear to that agent to keep advancing, so that when
> future work gets scheduled, it's offset by the time the agent took to run.

In Swarm, the way to model events with duration is by separate events that
model the start and end of each process.  (The end event can be omitted
if there's nothing significant that happens then).  What this means is that
you use a dynamic schedule, and reschedule an event to start the next work
interval sometime during the previous interval (or whenever else it's clear
that the work interval needs to be done).  If you calculate the duration
of the work interval while you're doing it, that means you offset the time
of the event that started the interval by the time it takes to complete,
and then reschedule at that calculated time.

In the demo apps, the one example of a dynamic schedule with calculated
times is the mousetraps model, but that doesn't involve a duration, only a
calculated start time.  It's the same idea, however.  In discrete-event
simulation terms, Swarm is an "event-oriented" as opposed to a "process-
oriented" simulation.  Breaking things down to the most atomic events,
those that start and end any interval, does require that you think about
this fine-grained structure and schedule events accordingly, but it allows
you to take greater control and express rules on event succession that
would be unavailable in any other way.

> I suppose I could just record the time before and after the work and use
> that, but it seems clumsy somehow... or maybe I'm just too tired to
> appreciate it...

It sounds like you're already doing a lot of dynamic scheduling in your
schedules, so it may be just a matter of using this time before and after,
and learn to appreciate the clumsiness!  I agree that it does involve a
bit more work to do things this way than just to have a built-in interval
for some process that gets calculated automatically, but in Swarm even the
notion of a linear measured time is only a convention.  The extra work
also means that you can model whenever some instantaneous or protracted
event is to have its effects.  In Swarm we've tried to avoid any compromise
of underlying expressiveness over convenience for particular applications,
since convenience can always be remedied through higher-level libraries.
So, embrace the clumsiness, and help define some libraries (or show us
some requirements) that can do your style of duration-style scheduling
more conveniently!

-Roger