Re: Scheduling question

[Sven N. Thommesen]

At 02:05 PM 9/28/1998 -0500, you wrote:
>Sven Thommesen originally asked:
>
>> I have 3 types of agents, each managed by an agent swarm created by and
>> owned by the modelSwarm.
>> 
>> The agent swarms are activated in the modelSwarm one after the other, which
>> means all agents of one type perform all their 'step' activities before
>> agents of the next type go.
>> 
>> I'd now like to split up the agent 'step' activities into substeps, and
>> have all 3 agent types do 'step#1' before they all get to do 'step#2'. 
>> 
>> How do I arrange scheduling to achieve this ? Is it possible to activate a
>> sub-activity of a swarm in the owner swarm, or do I have to move all
>> activation stuff up into the modelSwarm?
>
>and then answered Marcus's question:
>
>> >Would you first explain why it is useful to have a different Swarm for
>> >different agent types?
>> 
>> It seemed the ... orderly thing to do. Compartmentalization works. Objects
>> are good. (It is not *required* by my app, if that's what you are asking.)
>> 
>> I'm aware that I could solve my conundrum by pulling code back from the
>> agent swarms together into the modelswarm. Doing so would require a bit of
>> re-programming. 
>> 
>> I was just wondering if there is some wrinkle to using the scheduling
>> machinery that I don't know about that would solve the problem in some
>> other way.
>
>Splitting agent populations into subswarms is certainly part of the Swarm
>design philosophy, but the sub-populations would ordinarily defined as part
>of some structure of interaction within the model rather that just agent
>types.
>
>But to answer the narrow question about splitting up "step" actions: if the
>actions are all really scheduled at the same time value, then to the model
>they really are concurrent and subject only to the sequencing rules declared
>for actions at the same time step.  Right now, this is only to run them in
>the order in which they were originally scheduled, or in which they were
>activated within a containing swarm.  As you note, this does give you control
>over what order the step actions are to be performed in, but not to divide
>them into substeps at the same time value.
>
>If you want this degree of subdivision within a larger time window, the
>simplest solution would be merely to split your units of time into some
>finer division, and schedule all of the first step actions into a time unit
>on a first beat of your time clock and all of the second step actions onto a
>second beat, just to put some rhythm into your schedules.  You just have to
>be aware that this use of this clock value is purely artificial to get the
>special syncopated timing you want to perform.
>
>The complicated solution would be the ability to specify a custom "Concurrent
>Group Type" that you declare when you initialize a swarm, and that would
>interpret all concurrently scheduled actions from any subschedule to run
>in any manner that the concurrent group type imposes.  This mechanism is
>currently used internally by the scheduling machinery (for example, to
>sequence subswarms of a containing swarm to run in order of activation, when
>they happen to be scheduled on the time step).  It has a fairly complex
>internal interface, however, and is not currently documented for end-user
>use.
>
>The intent of concurrent groups is to provide a special handler to resolve
>conflict in the special case of actions that get scheduled to run
>concurrently even though they might otherwise run individually.  They seem
>like they'd be overkill to merely schedule actions that always occur in a
>completely repeatable sequence.  If you want to trigger step actions on your
>agents by type, you might just create three separate collections of the
>agents by type (instead of full swarms) and then schedule three "foreach"
>initial step actions on these collections followed by three followup actions
>to complete the step by type.
>
>--Roger

Thanks, Roger!

I must admit to my chagrin that I am not sure if your answer really
answered what I was trying to ask (the whole scheduling apparatus is in
dire need of a better Usage Guide, I fear) -- so let me explain in more
detail what the problem was, as seen from here:

given a ModelSwarm that owns 3 subSwarms, each of which manages a list of
Agents. Let's say each subSwarm schedules 3 actions, taken serially, on its
list of agents. The subSwarms are activated in the ModelSwarm serially. We
then get the following effective order of activity:

        subSwarm#1, activity #1 (for all agentType1)
        subSwarm#1, activity #2
        subSwarm#1, activity #3

        subSwarm#2, activity #1 (for all agentType2)
        subSwarm#2, activity #2
        subSwarm#2, activity #3

        subSwarm#3, activity #1 (for all agentType3)
        subSwarm#3, activity #2
        subSwarm#3, activity #3

Now instead I'd like the order of execution to be:

        subSwarm#1, activity #1 (for all agentType1)
        subSwarm#2, activity #1 (for all agentType2)
        subSwarm#3, activity #1 (for all agentType3)

        subSwarm#1, activity #2
        subSwarm#2, activity #2
        subSwarm#3, activity #2

        subSwarm#1, activity #3
        subSwarm#2, activity #3
        subSwarm#3, activity #3

The problem lies in the need (?) for all of a (sub-)swarm's activities to
be activated at the same time in the owner swarm.

I see two ways out:
(a) pull the agent lists back into the ModelSwarm; this would allow me to
order these activities as needed;
(b) create more subswarms, 3 for each agent type, so that each subswarm can
schedule one activity against one agent list; they can then be activated in
the ModelSwarm in the desired order.

Do you see any other solutions?

-Sven


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