Hi Maciek,
 
I needed the agents visualization because I need to see their contact patterns. The social network basically forms the bipartite graph of thier interactions which can be collasped to either partitions (agents or locations). Thank you for the codes, but I haven'h had time to look through. Is your preferential attachment model that of Barabasi?
 
By the way, I have tried almost all layouts in JUNG and the repainting of the agent frame is still slow. I read somewhere in JUNG's manual that there's a listener thread to detect any changes in graph properties and refresh the panel/frame automatically. This is currently what is happening with my application. When the agents have exhausted thier first iterations of activities, the edges in the bipartite graph would have also been linked. At this point in time onwards, the agent visualization will run smoothly (since there are no more changes in the graph, JUNG will not do anymore repaints).
 
I have also tried Sean's suggestions but the problem persists. I tried this using an older version of my codes where, somehow, JUNG doesn't regconize changes in the graph. In this version, I did manual repaints. With or without the "mini-schedule", the agent visualization is still jerky. But the visualization is smooth when there are no more edges to established. Perhaps Im missing out something. I need to review my codes again.
 
Regards,
Jimmy.

________________________________

From: MASON Multiagent Simulation Toolkit on behalf of Maciej M. Latek
Sent: Tue 10/10/2006 11:40 PM
To: [log in to unmask]
Subject: Re: MASON and JUNG Visualizations



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.