The Nodes Simulator

Nodes & Edges

This simulates boxes (nodes) suspended by elastic connectors (edges) in a gravitational field. The scene is a box with elastic/resistive walls having a non perfect elastic coefficient (thus experiencing a loss of velocity on rebound). Many of the ideas are taken from the wonderful GraphLayout demo that comes with the Java JDK and has hidden in it many great hints as to how to best manage threads and to implement the Controller - Model -View pattern.

The simulation is highly configurable, allowing you to try lots of different environments.

Force: This parameter sets the type of attractive force between the nodes. Currently the choices are Linear and Inverse Square.

Edge Style: The nodes are connectable in different ways:

Line: All nodes are connected end-to-end forming a single line.

Star: All nodes are connected to a single central node forming a star.

Loop: Like Line, but with the two end-points connected back, forming a rubber band.

Pendulum: A line with one node fixed to the middle of the ceiling, forming a compound pendulum.

Oscillator: Like Pendulum, but with two fixed points, one on the ceiling, the other on the floor.

Rebound: This parameter allows the "floor" of the box to add energy to the nodes when they run low. It kicks the node vertically with enough velocity to just reach the "ceiling" if unteathered. It also supplies a slight random horizontal velocity if it sees the node has only a vertical velocity component. When off, it supplies no additional energy and the system can naturally "run down".

Apply: The changes to the parameters do not take effect immediately. Use "Apply" to have the new behavior installed. If the changes are only to parameters and do not require a new set of nodes, the changes will be applied to the existing scene. So for example, changing the tension in an existing scene will not cause a re-randomization of the system. However, changing the basic node layout will re-randomize the scene.

File: The Applet can also be run as an Application. It does this by including a "main()" method. In this case, an additional control is made available to turn on/off recording of the individual events in a data file. This is used to graph and analyse the system later off-line.

Numeric Parameters: The various physical constants are adjustable.

Nodes: Changes the number of nodes in the scene.

Gravity: Change the "gravity". This in fact has nothing to do with "g" but simply the change in velocity each frame. The frame rate is roughly 30/sec.

Elasticity: The velocity loss at each rebound from walls, floor, and ceiling.

Tension: Changes the change in velocity of each node toward each other each frame. Like gravity above, but the "attraction" is between the nodes rather than between the node and the floor.

Mouse: The mouse serves two purposes. First, simply clicking on the scene will "catch" the nearest node, and freeze the action, allowing you to reposition the node. If the node is already fixed in place, such as with the Pendulum and Oscillator, it will remain fixed at the new location. Otherwise, the node is relaunched in the new position with zero velocity.

In addition, for the fleet of finger, a double click will change a moving node to a fixed one, and release a fixed node to be moving again. Thus the user can create their own Pendulum and Oscillator style of scenes.

Why?

This was done to prepare for the Complexity Summer School at the Santa Fe Institute. This area of computation could provide models of, and tools for, new development areas within Sun. In order to evaluate the use of this new technology, I'm immersing myself in the field for an intensive month-long study in order to get a sense of the field and where it could apply.

This Node Simulation is not at all "complex systems" in the Santa Fe Institute's use of the phrase, but simply a way for me to start thinking along the lines pointed to by Complexity Science, and sharpening up old skills in math and physics, and looking into Java's use in this area.

For example, Java's ease of development of Networking projects, availability of modern language constructs such as objects, threads, garbage collection, platform independence, extended numerics and so on makes it an ideal system for doing this work.

Areas of interest include:

Cache and Proxy Servers: How do we build a robust network services infrastructure that can be somewhat self managing and adaptive?
System Administration: How would a system "heal" itself naturally, recovering from disk failures as an example. What would I have to do to achieve absolute transparently replacing an older system with a newer one with no loss of data.
Security: The network is far to large and complex to orderly migrate into a secure form of itself. How do we do this naturally and incrementally?
Services: As more services evolve as the "killer apps" of the internet, how do these negotiate and barter among each other?
Appliances: As computing gets driven into light bulbs, traditional hierarchical device management and configuration techniques break down, they cannot scale to the size and confusion of this new world. How do we provide bottom up, emergent management of these swarms of devices?

Source

The program is modeled after the GraphLayout demo delivered with the Java SDK. Here is the NodesApplet source. The key idea making this all work easily it the C-M-V Pattern. Although this is not in its most pure form (where the nodes could be replaced with multiple differing views such as scatter graphs and the like), it has the separation of model calculation from that of the display. Specifically:

recalc(): This method is called every 1/30 of a second (frame rate) from the runnable interface's run() method. It keeps ticking during the running of the program, independent of any drawing or user interaction. It has one job only: update the positions and velocities of the nodes, pausing their calculations during the mouse down period.
update(): the update() method is called by the AWT's UI thread, which is entirely independent of the Nodes program's run thread. Typically these are difficult to coordinate, but with the clean separation of the two tasks, they suffer no difficult to control interference. The update() method is queued by the AWT whenever the window detects the application needs to refresh itself (after being uncovered by another window, for example). It is also manually queued by calling the repaint() method provided by the AWT for use by the programmer. We do this as the last step in our recalc() call. This has the side advantage of merging two repaint requests when they are co-queued.