On Sean's question, we are working toward expanding models that will require

1.a (a coral reef grid full of agents that is too big or too slow if handled

without parallelization), and possibly 1.b (3D corals, each of which are

each made up of hundreds of polyps). We will be tying into Lattice Boltzmann

and/or smoothed particle hydrodynamic models associated with both scales.

All of the discussions recently of various options have been of interest,

though an extension of Mason that would facilitate this would be of

considerable assistance. 



Cheers!



John McManus  



-----Original Message-----

From: MASON Multiagent Simulation Toolkit

[mailto:[log in to unmask]] On Behalf Of Sean Luke

Sent: Friday, December 07, 2007 8:58 AM

To: [log in to unmask]

Subject: Re: cluster or grid parallelization



There are three kinds of uses of parallelization here that I'd like  

to disambiguate:



0  Parallelizing an experiment within a single machine.



1. Parallelizing a single experiment by spreading it across multiple  

machines that work together.  This  commonly involves one or both of  

the following tasks.



	1.a Distribute the *space* of the world across multiple machines

	    because it's so big in memory

	1.b Distribute the *agents* of the world because their

	    computational cost is too large



2. Using multiple machines to do multiple experiments, one experiment  

per machine.





#0 is trivial.



For #2, shell scripts and rsh do just fine for us; indeed use of PVM/ 

MPI etc., is just way too heavyweight, particularly since Java and  

MPI don't play well together still.  #2 is also very cleanly done on  

grid computing solutions.  If anyone's interested, there's a company  

in my area (Parabon) which negotiates to borrow excess cycles on  

organizations' PCs and then sells this time with a Java-only piece of  

grid computing software.  For a large NASA project they've adapted my  

ECJ code to this system and I'm sure would be interested in tasks you  

might have in MASON.  Give 'em a call (parabon.com).



For #1, I'm very interested in knowing how people are adapting MASON  

(or RePast) to distribute their experiment.  Do you have 1.a as a  

need?  1.b?  How are you going about hacking MASON etc. to do it?



The reason I ask is that one of our grants may push us to look into  

creating a version of MASON which does #1 cleanly.  Note that MASON  

was specifically designed for #2, and indeed *good*, efficient  

architectures are very different between #1 designs and #2 designs.   

So we're going to have to think about what kinds new data structures  

will we need.  Probably at least we'll need a distributed schedule  

sync device, a way for agents to migrate, and several mechanisms for  

distributing space.  It's a lot of overhead.



I'm interested that some have mentioned RePast.  RePast etc. weren't  

designed for #1 *or* #2.  I know people have been hacking  

distribution onto RePast, and am interested in how they overcame the  

issue of the schedule containing single-machine Java events (repaints  

etc.).  It might help inform us when we get to working on this.



Sean