MASON-INTEREST-L Archives

December 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Glen E. P. Ropella" <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Fri, 7 Dec 2007 08:37:25 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (67 lines)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Luke on 12/07/2007 05:57 AM:
> 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.
>
> [...]
>
> Give 'em a call (parabon.com).

Excellent!  Thanks.  I didn't see a whisper of them on google.

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

I haven't done this yet; but, FWIW, I am interested in _both_ 1.a and
1.b.  Most of my simulations are hierarchical, which means spaces are
usually agents and agents usually contain spaces, and most of my agents
consist of sub-agents.  Hence, 1.a and 1.b are not usually cleanly
separated.

This sort of thing is pretty easy to do in Swarm (though the
parallelization is non-trivial, but straightforward).  I had hoped for a
relatively mature open-source version of something like Hyperion, cJVM,
dJVM, or JESSICA.  But I'm not finding anything mature enough to rely upon.

Also, FWIW, I really like MASON's simplicity and clean design.  So, I'd
argue against building a new _version_ of MASON to do any of this.  It
would seem better to make the core as flexible as possible and rely on
usage patterns for the application of the core.  To the extent
application required variants of units (packages, collections, classes),
then those variants could be usage-specific without adding unnecessary
complexity to the core.  As for your specific grant, perhaps the best
way to start such _is_ by developing a new version of MASON but to avoid
_merging_ them right away and look for minimal ways to modify the
original to support customization and extensibility.  One of the reasons
I've had to avoid RePast is because it comes with too much overhead
investment for my clients.

- --
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
The world henceforth will be run by synthesizers, people able to put
together the right information at the right time, think critically about
it, and make important choices. - E.O. Wilson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHWXbEZeB+vOTnLkoRAvxxAJ9J5a0ev1DvnP27Nv61Km4a038icACgu7vm
6stvQCkZV0fe90f3MIFZg/U=
=ZFhY
-----END PGP SIGNATURE-----

ATOM RSS1 RSS2