Talk:OpenSim: Difference between revisions

From OLPC
Jump to navigation Jump to search
(added talk with bemasc)
Line 13: Line 13:
= IRC w/ besmasc =
= IRC w/ besmasc =
bemasc: nteon: it sounds extremely amibitious
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
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?
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: 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: 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: 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: 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: unless you're a world expert in this stuff

bemasc: there's also the extremely tricky issue of numerical stability
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: 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?
nteon: do you have any links to ODE solvers?

bemasc: nteon: how about http://www.scipy.org/SciPyPackages/Integrate
bemasc: nteon: how about http://www.scipy.org/SciPyPackages/Integrate

bemasc: and odeint
bemasc: and odeint

bemasc: that's probably the most canonical one
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: 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: 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
bemasc: nteon: I should step back and say: I think this is a great idea

nteon: bemasc: thanks, I appreciate the critique
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: 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.
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
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: 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: what sounds hard to me is coming up with a usable interface for it

bemasc: maybe a GUI designer would say the reverse
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
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
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
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: 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.
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
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.
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: 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
nteon: and put off GIS till later

bemasc: I think that sounds pretty good.
bemasc: I think that sounds pretty good.

bemasc: I'm still skeptical about your engine
bemasc: I'm still skeptical about your engine

bemasc: In particular, I'm far from convinced that Runge-Kutta methods are appropriate here
bemasc: In particular, I'm far from convinced that Runge-Kutta methods are appropriate here

bemasc: because they are not unconditionally stable
bemasc: because they are not unconditionally stable

bemasc: which means that even with linear ODE's, RK methods can still blow up
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: 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"
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 ;) [[User:Bobbypowers|Bobbypowers]] 19:35, 2 April 2008 (EDT)
: 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 ;) [[User:Bobbypowers|Bobbypowers]] 19:35, 2 April 2008 (EDT)

Revision as of 23:36, 2 April 2008

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)