Answering your (old and cold, I know :-)) question below, our
MEME/Parameter Sweeper distributes Repast simulations (a la #2) using
Proactive and RMI calls.
It is fairly easy, albeit not simple. We didn't encounter any inherent
problems in doing that. To be very honest, I am not even sure what you
mean by repaint events, but I might misunderstand something. Obviously,
graphical observers are not distributed.
I am happy to answer further questions if you have them.
dr. Gulyás László | Laszlo Gulyas, PhD
kutatási igazgató | dir. of research
AITIA International Zrt. | AITIA International Inc.
> 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.