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)

Stepping back...

I agree that it is very ambitious, especially the geographic part.

But system dynamics and systems thinking is THE holy grail in science education. In any given field, it is absolutely fundamental - as important in biology as evolution, as important in physics as the principle of relative frames or the concept of energy, as important in chemistry as the periodic table. For this reason, it is assuming an ever-more-prominent place in science textbooks - those by Art Sussman, "Dr. Art", are breaking ground in this sense.

And tools for thinking about this are really lacking.

I think that the geographic part is an attempt to graphically relate "just a bunch of numbers dancing on the screen" to real-world problems that people naturally have intuition about. This is key, but I think that there are easier ways to do it.

Think of one of the simplest systems possible - a bucket under a tap with a hole in the side. The numbers involved can be represented graphically - flow in, flow out as line thicknesses; water in bucket as height; and even pressure as how far out it squirts (I know, velocity should technically reduce line thickness, but leave that out).

This kind of graphical representation of numbers is key. Pictographs, where every little baby icon represents a million births... to make this really usable by a teacher, I would include at least this feature on my basic requirements.

Homunq 12:22, 7 April 2008 (EDT)

Thanks for the support, I think it has the potential to greatly improve science education.  For now, I am going to forgo the geographic part to just focus on creating the modeling activity, and building in the basis for the kinds of graphical representations you're talking about. Bobbypowers 04:43, 10 April 2008 (EDT)