|
From: Nick C. <nic...@ve...> - 2002-12-13 17:52:17
|
Hi, That's great! When exactly do you leave? I feel like we should have a party for you, but not being anywhere near each other that might not work too well :). I agree, that is my head tells me, that #1 would be more useful given our current user base. As for which would be "cooler" to work on, I'd have to go with #2. nick On Fri, 2002-12-13 at 12:38, Laszlo Gulyas wrote: > Hi, > > Thanks for the clarifying notes. While I think both goals seem > worth pursuing, I was more like thinking about item #1. > Now that I come to think about it, I have a CS undergraduate > I advise back in Hungary, who already put a simple, but modular, > Condor-like framework together in Java. I might redirect him > to hook it up with Repast. > > This is in addition to another CS undergrad. who has agreed > to work on 'something for Repast'. Maybe, the two of them > could round up nicely what Tom has in mind.... > > I'll talk to them in January and get back to you! > > Gulya > > At 10:27 AM 12/13/2002 -0500, Nick Collier wrote: > >I also want to say that we have two goals with respect to distributed > >simulation. > > > >1. Do multiple batch runs on multiple computers from a single computer, > >collecting the data on that single computer. The idea here is to split > >the parameter space into pieces and explore these spaces individually on > >individual computers. This can be started and controlled from a single > >computer and the results should be recorded on that computer. Of course, > >something like this can already be done with Drone or Drone-like > >toolkits. However, our target hardware here is something like a > >computing lab full of win2K machines that are otherwise idle over night, > >or 4 or 5 scrounged and freely available windows boxes. > > > >This is not that difficult and shouldn't require a parallel distributed > >scheduler. > > > >2. Spread a single simulation run over multiple computers. This is more > >traditional distributed parallel computing and would require a > >distributed parallel scheduler. > > > >I'm not sure where we've decided to place our focus w/r to these two > >goals, although I know my heart and my head are divided here! > > > >Nick > > > >On Fri, 2002-12-13 at 10:09, Nick Collier wrote: > > > Hi all, > > > > > > I think there's a bit of confusion here. What's included in repast 2.0 > > > is not Mike's FAST framework (a framework for distributed repast -- more > > > or less -- simulations) but rather code that enables the true > > > parallelization of scheduled actions. The intention is that expensive or > > > long running actions can be scheduled to run in parallel with typical > > > sequential scheduled actions. > > > > > > Maybe Mike can say more about the relationship of something like FAST to > > > these new parallel actions. > > > > > > Anyway, my point is that repast 2.0 doesn't give you framework for fully > > > distributed parallel simulations out of the box. We are pursuing > > > something like this, however. Tom has looked into Globus, Condor and > > > lately ProActive (http://www-sop.inria.fr/oasis/ProActive/) in this > > > context. I think it will be a priority for him once he gets the current > > > round of GIS code sorted. Maybe he can say more, although I know he's > > > away for a few days at the moment. > > > > > > Nick > > > > > > On Fri, 2002-12-13 at 09:55, Frank Blecha wrote: > > > > > > > > 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 > > > > > > > > > > > > -- > > > Nick Collier > > > Social Science Research Computing > > > University of Chicago > > > http://repast.sourceforge.net > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > >-- > >Nick Collier > >Social Science Research Computing > >University of Chicago > >http://repast.sourceforge.net > > > > > > > >------------------------------------------------------- > >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 > -- Nick Collier Social Science Research Computing University of Chicago http://repast.sourceforge.net |