RE: [Repast-developer] Controller hierarchy

[Frank B. <fb...@bl...>]

I'm also curious as to the inclusion of that feature. - Frank

On Thu, 12 Dec 2002, Scholand, Andrew J wrote:

> 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
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
>