Hi All,

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.

Best regards,

-- Laszlo
-- 
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.
>
> Sean
>