Hi All,

Sorry for the delay in answering...

Maciek, thanks for mentioning MEME. The new URL is http://meme.aitia.ai/
-- a new version is to be out any day now... :-)

As for your question: MEME is free of charge, but not open source as of
today. We are looking into the option of making it open source, though.
And also, we are investigating whether we could make it work with MASON as
well, albeit that would certainly require some efforts.

Moreover, we actually have a project in the queue to address the issue of
supporting 'in-run' parallelization of ABM's. That is, we intend to
provide a few templates that would let you distribute your agents/space on
a pool of computers. (The idea is that for certain ABM interaction
topologies pretty efficient algorithms can be implemented and provided to
the user 'under the hood'. Obviously, this won't be a general solution,
but still could help.) The bad news is that we are planning to use Repast
as the base platform.

Best regards,

-- Laszlo
-- 
dr. Gulyás László        | Laszlo Gulyas, PhD
kutatási igazgató        | dir. of research
AITIA International Zrt. | AITIA International Inc.

> Dear all,
>
> 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?
>
> Regards
>
> Maciek
>
> On Dec 7, 2007 8:57 AM, Sean Luke <[log in to unmask]> wrote:
>
>> 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
>>
>