Let me add my two cents about #0 and #2. I guess everybody had their secret stash of sh scripts to do #2 nicely, but MASON would benefit from tool like MEME ( http://www.aitia.hu/model_exploration_modul1, since Mr. Gulyas was too modest to mention it). Is MEME open source?
With #0 and large number of computationally inexpensive and homogeneous agents, MASON could offer new Schedule construct. Using ParallelSequence is too expensive: it is not economical to spawn a new Thread for each agent when execution of agent is sometimes order of magnitude cheaper than relevant operations of ParallelSequence. It would be nice to have method something like scheduleRepeatingCore, that would result in schedule creating as many worker threads as there are cores in system, each of worker threads would than take a subset of agents scheduled using scheduleRepeatingCore and step them sequentially.
When proper care is taken, any activation scheme (sequential, random, Poisson) can be implemented. Or is there a better way to deal with simple agents?
There are three kinds of uses of parallelization here that I'd like
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
#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.