Public: Technology Reviews : Grid Computing
This page last changed on Apr 10, 2007 by stepheneb.
It is moderately straightforward. Normally it requires the attention at some point of a knowledgeable user/admin to install or setup software on all the computers used in the grid. So deployment to typical school environments is limited by the availability by this kind of person and of course whether the school technical policies and implementation even allow these changes.
One possibility is the Java Grid Engine: http://gridengine.sunsource.net/
Another option is Apple's Xgrid. Of course Apple has made the setup dead simple (if you don't have a copy of MacOS Server it takes a bit more work to setup the grid controller). Here's a good article about the Xgrid technology: Distributed Tiger: Xgrid Comes of Age, by Drew McCormack, 08/23/2005.
There appears to also be a Java client which would allow any computer that ran Java to be an Xgrid node:
Here's an ACM article: Building computational grids with apple's Xgrid middleware (pdf).
From the ACM article:
XGrid agent for Unix architectures: http://unu.novajo.ca/simple/archives/000026.html
Sure: if you can make a good argument for the pedagogic value in the delivery of more powerful dynamically constructed model simulations than can be done on one computer. I'll bet this is an easy argument to make. I've wanted to do computational fluid dynamics (see message from 3/8/07 subj: ideas for ALT/Computational Fluid Dynamics).
IN the modeling situations you envision what is the computational load breakdown between model computation and visual rendering?
QX: It looks like that we have two types of programs to be installed on a machine: agents and clients. An agent performs a task the controller assigns to it. It does not have a GUI and typically should run only when a computer is idle.
A client has a GUI that can be used to view and control an entire model being computed on a grid of agents. The full results have to be assembled by the controller and sent to the client 20-30 times per second. By using Jmol, we can probably achieve that FPS rate for 5,000 atoms on a single computer, given the CPU power left by RMI/RPC calls to update the system's state.
A client should probably not be an agent at the same time, because in a real-time situation the state updates through RMI/RPC and the visual rendering would keep the computer where the client resides too busy to spare CPU cycles for an agent.
|Document generated by Confluence on Jan 27, 2014 16:56|