Continuous system simulation in Python

[hrh1818]

In your simulator how much do you want Python to do?  I ask this
because your subject title implies you want to write your simulation
code in Python but a  simulator written entirely in Python would be
very slow.  Python is an interpreted language and pure Python code is
not suitable for simulating big  continuous systems. Hence to me it
appears you have two distinct proplems. One is developing a front end,
a user interface, that is easy to use. The other is either finding or
writing a good code compiler that wlll produce fast simulation code or
writing an interface to existing optimize simulation code.  Although
most likely not suitable for your applicaion but a good example of this
type of program is Mathematica. It is written in two parts a user
interface and a kernel that does all of the high power math.

Howard


Nicolas Pernetty wrote:
> > I am aware of some shortcomings and design flaws of Simulink,
> > especially in the code generation area. I am interested by
> > your paper nonetheless, please send me copy.
>
> Ok no problem. Let me just a few days to strip any irrelevant data on
> it...
>
> > However, Simulink is used by many people on a day-to-day basis
> > in the context of big, industrial projects. The claim that it
> > is "next to unusable" is, in my book, an overstatement ...
>
> Well the exact sentence is "next to unusable for our kind of projects".
> You'll see the details on the paper, but I'm not joking.
> For instance, under Simulink, our model is so big (well not so, but too
> big for Simulink obviously), that you may have a loss of up to 40x in
> performance compared to the model in C (how to optimize the Simulink
> model is a whole other subject in itself). So to make it usable, we have
> to use automatic code generation wich bring a whole new set of
> problems... BUT our work is *very* specific, and I'm not talking about
> Simulink in general. It may be perfect suited for others, it's just that
> for us it's far from perfect...
>
> > Scicos is not perfect either but you can hardly say that is
> > is a simple clone of Simulink. No time and space to go into
> > the details ...
>
> I wasn't in charge of evaluating Scilab/Scicos, so I can only talk about
> the conclusion : main motives to switch to Scilab/Scicos would be
> because it's free, that's all. Report said that next to almost
> everything Scilab/Scicos does, Matlab/Simulink can do, and more often
> than not, do it much better.
> So if you have a different report, I would be happy to read and transmit
> it...
>
> > Obviously, the python community is very dynamic, but how much
> > support will you get in the very specific topic of continuous
> > time systems simulation ?
>
> Well some people already offered me their help. But I believe
> that someone _has_ to begin alone some day...
> Otherwise people who work on continuous system simulation would never be
> interested in Python.
>
> That's the beauty of open source : do what you can, but do it ! and hope
> that someone else will come one day and use your work to build upon it.
> Step by step you will have something usable (in theory).
>
> > IMHO, an hybrid approach, such as the development of bridge
> > to include Python components into Simulink/Scicos/Ptolemy/
> > Modelica/pick_your_favorite_simulator may grant you more
> > interest from the simulation community.
>
> I already know some bridges like pymat or mlabwrap and I agree that a
> way to include Python to Matlab/Simulink would be a great step.
> But :
>
> 1) I think that it's Mathworks job to do it, and if they don't want to
> do it, we'll never have a very good integration.
>
> 2) For our kind of projects and our kind of developers (mainly
> non-IT engineers), I'm very reluctant to introduce too many different
> technologies in a project. If we decided to go for Python, fine, let's
> do the entire thing in Python/C. If we decided to go for Simulink, fine,
> let's do the whole thing in Simulink/Matlab/C. Matlab, for algorithms,
> can do almost the same things than Python and sometimes much better, so
> if you have already Simulink (and so have the license) why go for Python
> and struggle to have a good integration ?
>
> Regards,
>
> >
> > Cheers,
> >
> > SB
> >
> >
> >
> > Nicolas Pernetty wrote:
> > > Simulink is well fitted for small simulators, but when you run into
> > > big projects, I find many shortcomings appears which made the whole
> > > thing next to unusable for our kind of projects.
> > > That's why I'm interested in Python by the way, it is not a simple
> > > clone like Scilab/Scicos. It is a real language which bring its own
> > > advantages, and its own shortcomings, which I find well suited for
> > > our activity.
> > >
> > > If you want, I can send you a paper I wrote last year, detailing all
> > > Simulink shortcomings. I doubt that this mailing list is interested
> > > in such things...(and it's in French...).
> > > Concerning Scilab/Scicos, I'm not really interested in a technology
> > > primarily developed (INRIA and ENSPC) and used by France. Python and
> > > all its libraries and communities are so much more dynamic !
> > > And also I've heard that Scilab was developed in Fortran in a way
> > > which make it rigid and that the sources are poorly documented, not
> > > a good sign for an open source software (and Scilab isn't 'Free' for
> > > the FSF).
> > >
> > > Regards,
> > >
> > >
> > > *********** REPLY SEPARATOR  ***********
> > >
> > > On 8 Oct 2005 11:06:25 -0700, "Sébastien Boisgérault"
> > > <Sebastien.Boisgerault at gmail.com> wrote :
> > >
> > > >
> > > > Simulink is a framework widely used by the control engineers ...
> > > > It is not *perfect* but the ODEs piece is probably the best
> > > > part of the simulator. Why were you not convinced ?
> > > >
> > > > You may also have a look at Scicos and Ptolemy II. These
> > > > simulators are open-source ... but not based on Python.
> > > >
> > > > Cheers,
> > > >
> > > > SB
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Nicolas Pernetty a écrit :
> > > >
> > > > > Hello Phil,
> > > > >
> > > > > Yes I have considered Octave. In fact I'm already using Matlab
> > > > > and decided to 'reject' it for Python + Numeric/numarray + SciPy
> > > > > because I think you could do more in Python and in more simple
> > > > > ways.
> > > > >
> > > > > Problem is that neither Octave, Matlab and Python offer today a
> > > > > framework to build continuous system simulator (in fact Matlab
> > > > > with Simulink and SimMechanics, do propose, but I was not
> > > > > convinced at all).
> > > > >
> > > > > Regards,
> > > > >
> > > > > *********** REPLY SEPARATOR  ***********
> > > > >
> > > > > On 7 Oct 2005 11:00:54 -0700, phil_nospam_schmidt at yahoo.com
> > > > > wrote :
> > > > >
> > > > > > Nicholas,
> > > > > >
> > > > > > Have you looked at Octave? It is not Python, but I believe it
> > > > > > can talk to Python.
> > > > > > Octave is comparable to Matlab for many things, including
> > > > > > having ODE solvers. I have successfully used it to model and
> > > > > > simulate simple systems. Complex system would be easy to model
> > > > > > as well, provided that you model your dynamic elements with
> > > > > > (systems of) differential equations.
> > > > > >
> > > >
> >