RE: [Repast-developer] Controller hierarchy

[Scholand, A. J <aj...@sa...>]

Hi,

Work in this vein is often termed 'embarrassingly parallel' or parametric
computing - see for example NimRod/G,
http://www.globus.org/research/applications/nimrod.html.  Might be a good
tie in with Mike North's parallelized RePast engines, which I believe will
be in 2.0? 

Cheers,
Andy

-----Original Message-----
From: Skye Bender-deMoll
To: rep...@li...; nic...@ve...
Sent: 12/12/2002 1:11 PM
Subject: Re: [Repast-developer] Controller hierarchy


Hi nick, and folks,
   Was just remembering a conversation we had a long time ago about 
the idea of a ParameterSpaceExplorer, which seems relevant to the 
controller discussion.

Crudely, the idea is pretty much the same as doing runs from a batch 
file, but the batch file has a GUI and data presentation of its 
results.  So after someone has finished coding a model, and wants to 
explore "results" over a particular range of parameters, they could 
load the ParameterSpaceExplorer, enter the range, parameter sampling 
density, and number of repetitions per point, and come back in a 
couple of hours to a nicely collected data set.  Of course this 
requires that models have well defined stopping conditions (or a set 
number of steps), and report clear numeric results of some kinds.

In the (rare) case where there are two main input parameters of 
interest, and one result parameter, we could have nice 2.5D plots of 
results, or if multiple result params, allow switching between result 
plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
the user can say, "hmm, what's this discontinuity on the graph, is it 
just randomness?  lets do another 300 runs, more closely spaced along 
parameter-x, and see what we get..click click.."

Another advantage is that it might help people (us model coders) 
focus their (our) thinking on "OK, what are my inputs, and what are 
my results, and what does it mean" instead of just, "WOW! isn't that 
pretty!"  I don't by any means mean to dis good graphical 
representations of a sim, as I think they are incredibly important, 
but I think it is also good to help formulate a "question" and 
"results" approach as well.

I know it is better to do things than suggest them, but I've got all 
the java I can handle at the moment with this network stuff.  But I 
thought I'd throw the idea out there again, just in case coordination 
between DataSource, DataRecorder, and the Controller interface might 
be useful or necessary in the future...

cheers,
   -skye