MASON-INTEREST-L Archives

October 2006

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Maciej M. Latek" <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Tue, 10 Oct 2006 11:40:39 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
Dear Jimmy,

> I did a simple social network project with the agents in MASON and the
> network using JUNG. An edge is establish when 2 agents come into contact.
> So

By a propitious coincidence I was recently working with JUNG within MASON as
well, so maybe I can contribute. I'm pretty sure I have misunderstood
something and I'm oversimplifying, but you have got mobile agents, each of
them has some location and velocity, which at the same time double as nodes
in a dynamic social network.    

Unless velocity updates are independent of social network, I don't really
see the reason for using two frames. Jung display of the social network
should suffice, especially that it can be tweak so, that instead of simple
circle used to display a node you could have a circle with attached arrow
pointing in the desired direction with length proportional to speed or
something like this.  


> the social network). But the graphics become jerky with the agent frame
> whenever the social network is updating itself. Is there anyway I can
> improve on this? The number of agents/nodes is 50 and greater.

Everything depends on the layout you are using. In most cases, a
straightforward application of any of them to repaint a dynamic network each
MASON time step will result in display of many intermittent JUNG steps,
which makes things slower and certainly a lot uglier. The solution is to use
in your display following code, which prevents JUNG's VisualizationViewer
from repainting unless layout has fully finished it's job:

				layout.restart();
				while (!layout.incrementsAreDone()) {
					layout.advancePositions();
				}
				viewer.repaint()   

This works with most of the non-incremental layouts (for example, KKLayout).
It should  work with incremental layouts as well (FRLyout, don't call layout
restart than or you will loose benefits of incremental display), which are a
bit faster. Unfortunately, laying out any graph with many vertices each
MASON time step is costly, depending on machine, you might have problems
doing this real-time with more than 150-200 nodes. 

The things which puzzles me is the fact that by using any layout you loose
the information about agents locations: the ones computed by layout do not
necessarily correspond to the ones you use to for moving agents around. You
might consider giving up automatic laying out and writing up an simple
implementation of Layout interface which would make use of ForceMove method,
which would put a given vertex in the layout at the same position as the
physical one (see the JUNGs webpage, I think there is an example of exactly
this).

Last but not least, in order to speed up the calculations if you stick to
existing layouts, you can initialize them each MASON time-step with physical
locations (should be doable) and then do just a few calls to
advancePositions to improve the looks.

Anyway, if this helps there is a preferential attachment model in MASON with
JUNGs visualization available on my webpage (totally unofficial and
unfinished). You might want to look inside the JungDisplay to see a partial
integration of JUNG with MASON. JungDisplay was thought as a replacement of
Display2D for displaying a JUNGs graph structures, and is a mutilated
version of one indeed. The link for jar file is:

http://mason.gmu.edu/~mlatek/JungDisplay/JungDisplay.jar

and for the sources:

http://mason.gmu.edu/~mlatek/JungDisplay/src.zip


All hail to MASON,          

Maciek

Disclaimer: I'm not a programmer, I have been tinkering with Mason and Jung
for three weeks, I have no association with Mason team, so don't believe
even a single of my words. 

ATOM RSS1 RSS2