Talk:OpenSim

Very interesting. Generally, I think this would make for an excellent activity, and your application shows you've given it serious thought and appear ready to take it on.

The one section which seems out-of-place to me is the "Metropolis" (I think you mean Micropolis) one. Sure, system dynamics approach could make this kind of game better (simcity had very very limited means for positive/negative feedback, AFAICT). But Micropolis (that is: agents, graph analysis (roads and power grid), icon-grid based display of multiple factors), is a whole nother project, and you are already proposing two fair-sized ones: a system dynamics editor, and geographic capability for that editor.

One more comment: if you are doing geographic sims, you will need real optimization if it is to run at a decent speed on the XO. You haven't addressed this issue - would you use numPy, C (some known library, your own code), ...?

Homunq 11:58, 27 March 2008 (EDT)

Great, thanks for the suggestions! I've been saying and spelling Micropolis wrong for the past 2 weeks, I can't seem to stop... I also addressed your concerns in the main page, particularly the optimizations - I'll be using the LLVM JIT which can run a variety of optimizations before compiling the simulations into native code, ensuring we get the best performance and battery life we can!

Bobbypowers 13:11, 27 March 2008 (EDT)

IRC w/ besmasc

bemasc: nteon: it sounds extremely amibitious bemasc: nteon: it's important to remember that no matter how awesome your engine is, it's useless unless there's a finished, usable GUI on top nteon: bemasc: ideas on which parts to scale back on? bemasc: nteon: the LLVM stuff seems like a classic case of premature optimization. At a minimum, I recommend that you write a totally naive _interpreter_ (not code generator) for solving the differential equations bemasc: nteon: I think you may find it's faster than you expect, and dynamically compiling programs to run the simulation is not necessary bemasc: nteon: and even if it is too slow, your next sensible option is to use a pre-existing ODE solver library, of which there are many bemasc: frankly, I suspect that the existing ODE solver libraries (written in C or even Fortran) are probably faster than anything you're likely to whip up in LLVM bemasc: unless you're a world expert in this stuff bemasc: there's also the extremely tricky issue of numerical stability nteon: i do have a bad habit of trying to jump in over my head, but I do have the JIT working now (as of a few hours ago) https://opensimproject.org/wiki/OpenSimOutput nteon: do you have any links to ODE solvers? bemasc: nteon: how about http://www.scipy.org/SciPyPackages/Integrate bemasc: and odeint bemasc: that's probably the most canonical one bemasc: things get much nastier when you go to PDE's. In fact, there's almost no such thing as guaranteed stability for numerical solution of nonlinear PDE's. bemasc: also, as you noted, the amount of horsepower involved to get sensible results is huge bemasc: nteon: I should step back and say: I think this is a great idea nteon: bemasc: thanks, I appreciate the critique bemasc: it's basically a way for students to get into differential equations without having to learn all the mechanics of calculus bemasc: I just want to make sure that we don't end up with a super-advanced but semi-functional engine, and no usable Activity. nteon: bemasc: in that case I have no problem spending more or all of the summer working on the activity, I would love for it to be as "OLPC" as possible bemasc: perhaps it's a matter of perspective. I'm a numerical algorithms person myself, and so the numerical angle sounds fairly straightforward bemasc: what sounds hard to me is coming up with a usable interface for it bemasc: maybe a GUI designer would say the reverse nteon: bemasc: I've been primarily doing GUIs for the past year, so I'm a little less worried bemasc: nteon: ok. My #1 recommendation is: figure out the least advanced, least impressive feature set that you could possibly release nteon: bemasc: I have mockups in my head, but no time to sketch them out: 6 hours of class a day and two large projects due the end of the week bemasc: nteon: and then put that as early in the roadmap as possible bemasc: if I were judging applications (which I'm not), that would tell me that the proposer understands that deadlines always slip, and that a minimal product is much better than no product. nteon: bemasc: great. yes, that sounds good bemasc: I think people will be much happier to read about advanced features if they're explicitly to be done _after_ initial release. nteon: bemasc: as I said (I think?), I have the engine JITing simple models today, so I think by the beginning of the summer it should be in shape where it can just be used. Then perhaps I can target the first 6 weeks towards an initial GUI release, and then plan on a week for improving the engine (as I'll have had 6 weeks of use to figure out its foibles) and the rest of the time towards improving the GUI nteon: and put off GIS till later bemasc: I think that sounds pretty good. bemasc: I'm still skeptical about your engine bemasc: In particular, I'm far from convinced that Runge-Kutta methods are appropriate here bemasc: because they are not unconditionally stable bemasc: which means that even with linear ODE's, RK methods can still blow up bemasc: So I would probably recommend Implicit Euler or something similar, initially bemasc: Also, if your models are all linear, then it's possible (easy) to compute the solution "exactly"

I had to leave at this point, but I don't think restricting models to ones that can be solved analytically is a necessary or desirable constraint. Certainly simple systems can be solved this way but larger models can not, and I don't see why we just can't ensure that we keep small enough time steps and use the appropriate methods to keep the numerical solution close to the analytic one, if it exists. Also, as I'm working on this over the next 2 months, I am more than open to suggestions and its not directly part of my GSoC proposal ;) Bobbypowers 19:35, 2 April 2008 (EDT)