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.