[Pyarie-users] simultaneous solutions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Forwarded from the SimPy users list.

-------- Original Message --------
Subject: Re: [Simpy-users] Continuous system simulation in Python
Date: Wed, 12 Oct 2005 03:16:59 +0200
From: Nicolas Pernetty <nic...@ya...>
To: sim...@li...
References: <200...@sm...>=20
<434...@en...>=20
<200...@li...>=20
<434...@en...>

Hi John,

I've had a long loog at Pyarie and SimPy.
Good news is that I've understood almost everything (thanks to the
Python clear syntax and to the comments !) and that I had no problem
running your example (even managed to create new ones).

I think that I can build upon your work without too much difficulties.
I need some more time to digest everything and to clear my head before
giving you a full review, but something that I haven't quite grasped is
how can we manage multiple models/process ?

For instance, let's say we have a closed system : A and B have effects
on C and C has effects on B.
In a procedural language, I'll do the loop like this :

10:
computeA(stateA, outA)
computeB(stateB, outC, outB)
computeC(stateC, outA, outB, outC)
goto 10

In reality we can have a much more complex tree, so do we have to
somehow design a solver which deduce the tree call from the informations
or do we have to input the tree as well ? I think that somehow it is
already solved in SimPy...

As for my line of work, I'm involved in multiple mechanical bodies
simulation. For instance I can model an airplane, with the engine, the
wings, gravity and atmosphere as well as an autopilot.

Ok, give me at least 1-2 weeks to play and tweak with Pyarie/SimPy
before fully understand what I can do with it.

Thanks again for your help,

P.S. : sorry for my poor english, but it's really late and I'm really
tired... ;-)

*********** REPLY SEPARATOR  ***********

On Mon, 10 Oct 2005 16:25:49 -0700, John Pennington Metta
<pen...@en...> wrote :

> Nicolas,
>=20
> Multiple solution routines should be trivial in Pyarie. It's based on=20
> the simultaneous (with respect to timestep) solution of a system of=20
> equations. Each system (e.g. a nitrogen cycling model) is built as a=20
> class, with member functions for each equation (i.e. organic nitrogen)
>=20
> or sub-routine within an equation.
>=20
> The system doesn't care how the equation is solved. In other words, it
>=20
> matters not whether you use mathematics or define a routine to look up
>=20
> values in a table. You could even define the function in such a way
> that  it looks up a value and if the value can't be found in the
> table, then  calculates it and adds the calculated value to a table
> for later use.
>=20
> This all, of course, assumes that you are using the system in such a
> way  that each state variable is defined by a function. I'd be
> interested in  learning more about what you're doing and what you
> need. As the  documentation states, I designed this for my use in
> river ecosystem  modeling, but I'd like it to be as generally usable
> as possible.
>=20
> Cheers,
> -J
>=20
>=20
> Nicolas Pernetty wrote:
> > Hi John,
> >=20
> > Thank you for your answer. I've just downloaded the package and will
> > have a look on it next week.
> >=20
> > About continuous system modeling, I'm personnaly involved in
> > mechanics system simulator (2-3 body linked together) and found it
> > extremely difficult to design the basic sets of equation without
> > approximations. Results are often hugely complex and slow.
> >=20
> > We have tried to use readily available generic simulator (like
> > SimMechanics) but without success.
> >=20
> > We decided to assume approximation, and thus managed to dramatically
> > simplify the set of equations, which we implemented 'by hand' in C.
> > Problem is that such approach has to be unique and repeated each
> > time someone has to design a simulator (because approximations are
> > different).
> >=20
> > Another constraint I have is that some parts of the simulator has to
> > be run by data files. Indeed some parts are so difficult that it is
> > useless to try to represent it by equations. So some other people
> > use different method (like finite elements computation) and give me
> > the result in the form of data files. For instance for an airplane,
> > I can have time vs mass vs flow in the data file.
> >=20
> > So my simulator is composed of equations, data files and some
> > solver. How can I design a generic program capable of handling every
> > situations is my current problem ! ;-)
> >=20
> > I would be happy to build on your project (if possible) and made it
> > available to the Python community...
> >=20
> > I'll keep you informed of my progress,
> >=20
> > Thank you again,
> >=20
> > *********** REPLY SEPARATOR  ***********
> >=20
> > On Fri, 07 Oct 2005 08:07:34 -0700, John Pennington Metta
> > <pen...@en...> wrote :
> >=20
> >=20
> >>Nicolas,
> >>I'm working on Pyarie (pyarie.wikisophia.org), a system designed=20
> >>(theoretically) to take an arbitrary set of equations and solve
> >them,  >tracking system or state variables, using a variety of
> >solution >methods  (Runge-Kutta, etc).
> >>
> >>It's functional right now, but needs a great deal of cleaning up and
> >>has  a lot of gaps (probability distributions, etc.). I was
> >originally >
> >>writing it for some modeling I'm doing for my thesis, but we took a=20
> >>different path, so it's on a bit of a hold.
> >>
> >>There is one version that would probably be fine for you and which=20
> >>works. It just requires the user to build his/her equations and=20
> >>variables (along with timestep, output timestep, initial conditions,
> >
> >>etc) into two modules. After which the model will run, and spit all
> >>the  state variables at each output timestep to a text file which
> >you >could  graph (I linked it successfully with gnuplot at one
> >point, and >it ran  and output graphs transparently).
> >>
> >>The link with SimPy is that continuous modeling is essentially
> >>discrete,  in that we have to solve most equations at each timestep.
> >>So SimPy is  the backend to the software, controlling the solution
> >to >the equation as  a discrete processes at the given timestep.
> >>
> >>For a non-programmer, the current pre-alpha version is
> >non-functional, >
> >>but for you it would work fine (the programming you have to do is=20
> >>essentially just entering your equations correctly). Please feel
> >free >to  email me if there are any questions (which there will be),
> >but I >think  there's still a sample model included (testmodel.py
> >holds the >equations,  testsimulation sets up the initial variables,
> >solver, >timestep, etc.)
> >>
> >>Also, let me know what you'd like to, or do, change. I'm always=20
> >>interested in making this better for others. Eventually I'll clean
> >it >up  and publish it.
> >>
> >>Cheers,
> >>-J
> >>
> >>p.s. I just noticed that some fiends completely erased every page of
> >>the  wiki-based home, so I'll have to modify that so no-one can edit
> >>it, and  replace all the information.
> >>
> >>
> >>Klaus Muller wrote:
> >>
> >>>Hi Nicolas!
> >>>There has been some work on continuous system simulation in Python:
> >>>
> >>>1) traffic simulation (using SimPy, too):
> >>>http://bitsko.slc.ut.us/blog/prt-lrt-sim.html
> >>>2) a paper presented at EuroPython 2005:
> >>>http://www.python-in-business.org/ep2005/talk.chtml?talk=3D2273&trac
> >k=3D646 >>3) an excellent book: "Python Scripting for Computational
> >Science" >>by H. P. Langtangen (Springer)
> >>>
> >>>If you find out moe, please, let us all know. We may yet be able to
> >>>make SimPy a hybrid simulation package.
> >>>
> >>>Klaus M=FCller
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: sim...@li...=20
> >>>>[mailto:sim...@li...] On Behalf Of=20
> >>>>Nicolas Pernetty
> >>>>Sent: Friday, October 07, 2005 1:16 AM
> >>>>To: sim...@li...
> >>>>Subject: [Simpy-users] Continuous system simulation in Python
> >>>>
> >>>>Hello,
> >>>>
> >>>>I'm looking for any work/paper/ressource about continuous=20
> >>>>system simulation using Python or any similar object oriented=20
> >>>>languages (or even UML theory !).
> >>>>
> >>>>I'm aware that SimPy is for discrete event simulation, but=20
> >>>>maybe you would have heard of any similr work on continuous=20
> >>>>system. I would like to develop a generic continous system=20
> >>>>simulator, and so would be eager to join any open source=20
> >>>>effort on the subject.
> >>>>
> >>>>For instance, it would be useful for modelling an airplane=20
> >>>>with all the dynamics (flight simulator).
> >>>>
> >>>>Python is my language of choice because of the keyword=20
> >>>>'generic'. Being an object oriented dynamic language, it's=20
> >>>>perfect for such a task.
> >>>>Unfortunately I'm a novice when it comes to object oriented=20
> >>>>design and development, so I would prefer to start from=20
> >>>>something already existent instead of starting from scratch.
> >>>>
> >>>>If you had any idea on the subject, I would be really glad to=20
> >>>>discuss it with you.
> >>>>
> >>>>Thanks in advance,
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.Net email is sponsored by:
> >>>>Power Architecture Resource Center: Free content, downloads,=20
> >>>>discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> >>>>_______________________________________________
> >>>>Simpy-users mailing list
> >>>>Sim...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/simpy-users
> >>>>
> >>
>=20

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Simpy-users mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simpy-users

--=20
John Metta (yes, my name has indeed changed...)
http://oregonstate.edu/~penningj/
"A computer without windows is like a dog
     without bricks tied to its head."