From: Alan Chen Date: 2005-07-14T02:15:50+09:00 Subject: Re: Design question: use of OO for scientific simulation... Egg wrote: > * The basic sequence of interaction is: 1, store some death rates. 2, > infer some parameters from them. 3, run some simulations. 4, infer > some more parameters from those simulations. 5, display it all in a > couple of different ways. > > Anyway, I was wondering if anyone has done anything that they liked > with a situation like this, and could share a pattern or two. The > closest design problem might be analysing and simulating genetic > sequences, if that matters. I don't know how long it takes for your simulation to execute, but I run simulations (aerospace) which can take anywhere from under a minute to days on end. In my case the simulation itself is C++, but we've implemented a lot of utilities in ruby -- input parameter permutation, queue execution, post-process, and automated post process, plot generation and packaging). Even if your core sim is in ruby, I think it is often worth splitting up the actual simulation core from your pre and post analysis tools. If your organization doesn't mind you opening ports and running webservers, a wiki is nice to post simulation data to, and it's easy to annotate the output pages with notes. I'll mention RuWiki as a blatant plug for the wiki that I started and Austin Zeigler has really picked up and carried along (Project page at http://rubyforge.org/projects/ruwiki/ and demo at http://ruwiki.rubyforge.org/). RuWiki may actually be nice for you as it has a fairly simple file system backend for which you could directly write simulation output pages. I'm sure many other wiki's both in Ruby and other languages would give you a nice ranges of choices. Depending on how simple the inputs for your simulation are, you could even try a fitnesse style operation, where the inputs are entered into a wiki page and the server will come along and execute the scenario. If your simulation model is anything like mine in complexity though, this isn't really a feasable option though... HTH - alan