Top-Down and Bottom-Up Scheduling in Swarm

A comparison of implementations

Paul E. JohnsonUniversity of Kansas

Overview Agent-Based Modeling and the

“bottom-up” objective Top-down scheduling Bottom-up scheduling strategies Verification

ABM and bottom-up modeling Autonomous individuals Limited information Experiential learning Polymorphic modeling

But Scheduling is still Top-Down Standard cellular automaton.

“Freeze” a snapshot of the grid Update cells against snapshot Flush all updated cells onto grid Repeat

Examine Many Swarm Apps Agent design/philosophy is bottom-

up Scheduling is top-down

Agents are kept in a list They “step” (do something”) when told

to do so. Agents have no notion of “time”

although they are aware of things changing

Heatbugs Traditional Swarm-1.0 approach

createActionForEach actionForEach = [modelActions

createActionForEach: heatbugList message: M(step)];

Swarm-1.0.5 introduced “randomized” traversal of the list by allowing

[actionForEach setDefaultOrder: Randomized];

Heatbugs-2.1 FAction framework Create a “call” object and then have

each agent respond to that call.id call = [Fcall create ….]; actionForEach = [modelActions

createFActionForEachHomogeneous: heatbugList call: call];

Bottom-up Scheduling Ideal world: agents “decide for

themselves” when to act Discrete Sim Libraries must

integrate these many disparate behaviors so that they “fall into a common time line”

Time is a conveyor belt:

Harmonize actions across levels

2 Approaches for B-U Scheduling Master Schedule Decentralized Autonomous

Schedules

Master B-U Scheduling Create one Schedule object in

ModelSwarm level In each agent, at create time, tell

agent about Schedule.- setSchedule: id <Schedule> aSched;

Agent’s step method: Carry out actions for “current time” and Place “step” method on schedule for

future time.

Master Schedule in Mousetrap Mousetrap “dynamic schedule” is

an intermediate example One Schedule created in Model Swarm Agent’s (mouse traps) are not aware of

Schedule, but instead they “trigger” and tell Model to trigger some other trap at some future time

[modelSchedule at: n createActionTo: trap message: M(trigger)];

Complication: Concurrency What if several agents “schedule

themselves” at a given time? Ordinarily, actions in Swarm

schedules are ‘first come, first serve’

Possible to randomize actions when a cell is reached:

Concurrent Group Options

Concurrent Randomization id groupProto = [ConcurrentGroup

customizeBegin: self]; [groupProto setDefaultOrder: Randomized]; groupProto = [groupProto customizeEnd]; agentSchedule = [Schedule createBegin: self]; [agentSchedule setConcurrentGroupType:

groupProto]; [agentSchedule setAutoDrop: YES]; agentSchedule = [agentSchedule createEnd];

Decentralized B-U Scheduling Each agent is a Swarm with a

Schedule Activate each within “agent swarm” Agent tells self to “step” at future a

future time point by putting action on its own schedule.

Swarm able to integrate actions across all agents.

activateIn: is magic

When a schedule is activated in a Swarm, each time step (t):

“clears” all the actions on that cell at t

And It traverses all time t cells in all

Swarms that are activated in it

How Does Swarm Do it? Synchronization is the key word At each time step, each Swarm

“scans” all lower Swarms to see if they have actions to be executed.

Default: “first on, first off”

Randomization Customization (post Swarm-2.1.1) pjrepeater*.m

Step 1/5: create AgentSwarm (a container)

Step 2/5: customize ConcurrentGroup(same as previous groupProto)

Customize “container swarm”

Step 3/5: customize a Schedule object syncSched = [Schedule customizeBegin: self];

[syncSched setConcurrentGroupType: groupProto];

[syncSched setAutoDrop: 1]; syncSched = [syncScheduleProto

customizeEnd];

Set Sync Type! Step 4/5: customize the “container

Swarm” with Schedule agentSwarm = [AgentSwarm createBegin:

self]; [agentSwarm setSynchronizationType:

syncSched]; agentSwarm = [agentSwarm createEnd];

Put agents into context Step 5/5: Activate citizens inside

context of container (AgentSwarm).

[citizenList forEach: M(activateIn:):self];

How do we know it works? Take a complicated model Design it to compare both

implementations Compare results!

My Monster Opinion Project Agents move, interact, adjust in

here:

Time passes in days Each day has 10 timesteps Agents can go and come back Randomly decide to interact. “Catch-as-catch-can” interactions Compare Master Schedule versus

Fully Decentralized Scheduling 500 runs for each type (same seeds)

Conclusions Either implementation is fine! Master Schedule simpler to

implement Decentralized Scheduling slower!