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