 |
 |
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 >