|
From: Laszlo G. <gu...@la...> - 2002-01-11 01:08:08
|
Hi Michael, First of all, thank you for the long and thoughtful answer. I do share your view that reproducibility is an important and complex issue. In fact, in connection with my teaching activity one of my long term projects is to put together a 'best practice' manual on the statistical aspects of our computational experiments. (I think this is one of our weak points as a modelling community. Very few of the published models account for their exact design of the replicative experiments. In most cases [including my own work], it is simply stated that the results are based on, say, 30 runs. But no word on how the seeds were selected or what the confidence interval of the result would be, etc.) As for the multi-threaded scheduler, I was happy to read about your thoughtful design. It made be much more comfortable than I was after reading the original note about it coming. Of course, it was all my fault to be too worried about it, after all the quality work that has already went into Repast. Gulya At 04:09 PM 1/7/02 -0600, you wrote: >Gulya: > >Insuring that simulation results are reproducible is >clearly an critical issue. It should be noted that >guaranteeing reproducible results is a concern that >goes well beyond multi-threaded scheduling. For >example, the introduction of random numbers into >simulations, as is commonly practiced with agent-based >modeling, requires careful attention to insure >reproducibility. Furthermore, the implications of >reproducibility require thoughtful consideration since >most simulations that use random numbers are valid >only when run in a stochastic mode. Individual runs >of such simulations may be useful for model debugging >but should not be used to draw scientific conclusions. > >That being said, while multi-threaded scheduling in >Java is non-deterministic even within a single virtual >machine, multi-threaded programs still can be >deterministic. It all depends on the way that the >programs are written. > >The new multi-threaded scheduler is being developed >using the "Principle of Least Astonishment." Thus, >by default, the scheduler will operate in a >deterministic, single-threaded mode. This will >prevent breakage of existing programs and new >programmers alike. > >Multi-threaded scheduling can be activated on a >case-by-case basis by specifying both a start time and >an end time for tasks. The start time is the >simulation scheduling time you are already familiar >with in RePast. The end time defines when the >results of a given task are available for other tasks. >These other tasks may be run on separate, concurrent >threads. Details such as thread pooling and >concurrency control will be automatically handled by >the new scheduler. Note that the end time is in the >same units as the start time, which is to say units >of simulation time, not wall clock or process time. > >Given a set of valid concurrent tasks, a new task can >properly be started if the start time of the new task is >less than or equal to the minimum end time of all of >the currently running tasks. This is true since the end >time states when the results of a given task are available >for other tasks to use. The scheduler will use this >rule to select tasks to be run concurrently. It is up >to model developers to properly specify end times if they >wish tasks to be concurrent. The details of managing and >using this information will be embedded within the new >scheduler. The new RePast scheduler will thus make >multi-threading available by simply adding optional >simulation clock end times to the standard scheduler >method calls. > >Clearly, proper use of multi-threading will require >model developers to correctly set task end times. >Choosing to use this new feature will thus create a >new responsibility for developers. However, which >powerful programming feature can be used carelessly >yet effectively? > >Michael > >-----Original Message----- >From: Laszlo Gulyas [mailto:gu...@la...] >Sent: Sunday, January 06, 2002 9:38 PM >To: rep...@li... >Subject: [Repast-developer] Question on New Scheduler > > >Hi Everybody and Happy New Year to All, > >I seem to be lagging back on all the issues here, and I am >sorry for that. > >My question here is about the new scheduling mechanism >in the works that has been announced some weeks ago. I >have to tell, it sounds terrific in general. What I am >worried about, however, is replicability of the simulation results, >when using multi-threaded scheduling. As far as I know, >but I might be wrong of course, the exact scheduling of >threads in Java is undeterministic (at least, accross >JVMs). Am I right on this? If yes, can we still somehow >guarantee that the simulation results will be reproducible? > >Well, that's it. Thanks for the answers in advance, and >I am sorry if this what I wrote makes no sense. > >Gulya > -- >Laszlo Gulyas (617) 384-9216 >Government Dept. Weatherhead Center >602C Coolidge Hall for International Affairs >1737 Cambridge str. Cambridge, MA 02138 > >_______________________________________________ >Repast-developer mailing list >Rep...@li... >https://lists.sourceforge.net/lists/listinfo/repast-developer > >_______________________________________________ >Repast-developer mailing list >Rep...@li... >https://lists.sourceforge.net/lists/listinfo/repast-developer -- Laszlo Gulyas, MSc Phone: (617) 384-9216 Government Department Weatherhead Center for International Affairs Harvard University 602C Coolidge Hall 1737 Cambridge street Cambridge, MA-02138 |