[SciPy-Dev] Pythonic Simulink clone... - how much interest?

burley burley@zonnet...
Tue Nov 16 12:46:26 CST 2010


I've looked at Pylab but development seems dead...; couldn't find any code
either...

To add to the complexity, in 1998 I was already looking into the Modelica
scene (https://www.modelica.org/), wrote actually a Python parser for that
language. Several tools (commercial and quasi-free...) are available: see
https://www.modelica.org/tools and in particularly (optimization oriented)
JModelica (http://www.jmodelica.org/) which has Python as extension
language.

Modeling in Modelica goes beyond the usual data-flow paradigm in that it
leaves the specification of the data-flow direction out of the modeling
session. Components are connected through interfaces with bi-directional
data-flow possible. Data-flow direction is problem solving specific, rather
than modeling specific. Thus, dual modeling efforts (for simulation and
inverse, system identification problems) are collapsed into one. My feel is
that Modelica progress and acceptance has been slow over more than 10 years,
probably because of the intricacies involved.Therefore, I think a
Python-based Simulink-ish clone would suffice more than enough.  Modelica
related publications, however, probably contain substantial guidance on how
loop unrolling could be done from a directed data-flow network.

It's a pity with all Pythonic power available that it misses the visual
programming interface to it. Sage (www.sagemath.org) is great but not really
an alternative either. After a serious research effort, and considerable
brain torture, I had to default to Scilab/Xcos, because communicating your
ideas to others (less mathematically inclined) is crucial for acceptance.
We'll see... ("Interfacing" Python with Scilab/Xcos will have to go through
HDF5 files....:-(

-- Burley

On Tue, Nov 16, 2010 at 19:14, Joshua Holbrook <josh.holbrook@gmail.com>wrote:

> > this sounds a bit what pylab works tries to do
>
> Only sort of.  What Simulink does is significantly different from what
> your typical graphical dataflow language does. What LabView, Pypes,
> Pylab, etc. try to do is basically supply a graphical version of unix
> pipelines.  Simulink, on the other hand, is used to describe and solve
> block diagrams like what you see in control theory:
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Control_theory
>
> without making you have to convert it into a state-space
> representation yourself.  This is handy because some dynamical systems
> are more natural to think about in terms of this block diagram
> representation than in a more state-space-friendly manner. Anyways,
> I'm not sure anybody else has implemented anything quite like
> Simulink. Afaik, there are lots of graphical dataflow languages (Like
> I said, I think an abstracted-out graphical flow diagram
> representation tool would be valuable) but not very many
> controls-style block diagram solvers.
>
> Fwiw,
>
> --Josh
>
>
> On Tue, Nov 16, 2010 at 8:55 AM,  <josef.pktd@gmail.com> wrote:
> > On Tue, Nov 16, 2010 at 12:29 PM, Joshua Holbrook
> > <josh.holbrook@gmail.com> wrote:
> >> On Tue, Nov 16, 2010 at 2:48 AM, burley <burley@zonnet.nl> wrote:
> >>> Visual modeling support as offered by the Simulink/Matlab and
> Xcos/Scilab
> >>> suites is very powerful, for the modeler as well as in communicating
> >>> concepts and ideas to others. Neither is Pythonic or extendable by
> Python,
> >>> unfortunately (disregarding the prohibitively expensiveness of
> Sim/Matl).
> >>> Wouldn't it be *very* nice to have a free (LGPL++?), user extensible,
> Python
> >>> based Simulink alternative, based on Numpy, SciPy,  Wx and/or
> Qt-like, and
> >>> the rest. All (e.g. most of) the algorithms are there, many would
> benefit. I
> >>> know of Viper (Tcl/Tk), Elefant (Bayesian Learning), ... but none of
> them is
> >>> general purpose or flexible in its use. Only a collaborative effort may
> make
> >>> that happen I would believe. What's the community interest in such an
> >>> effort? (I for myself am not a GUI programmer...).
> >>>
> >>> -- Burley
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev@scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>>
> >>>
> >>
> >> I've done some thinking on this problem, though I haven't had the time
> >> to pursue anything directly. I started working on a graphical
> >> front-end for dataflow-family languages in javascript, but didn't get
> >> very far.
> >>
> >> I would say that there are two major issues that come in trying to
> >> build something simulink-esque.  The first, obviously, is the issue of
> >> being able to build block diagrams in some sort of GUI and then
> >> translate those to a computer representation of a directed graph.
> >> While I think it's not something to be ignored, it's definitely been
> >> done before, and I think a nice way to describe these sorts of
> >> directed graphs in some sort of text format (python would work ;) )
> >> anyway--so, working from a computer representation first and making a
> >> gui tool tool to build said representations second could be the way to
> >> go. In fact, I think a generalized block diagram component would be
> >> pretty awesome, since there are many worthwhile variations of the
> >> graphical dataflow format besides Simulink (Yahoo! Pipes/Pypes,
> >> LabVIEW, PD, Excel).
> >>
> >> The other part, and the one that I think makes this actually
> >> difficult, is converting the block diagram into a solution. My
> >> understanding of what Simulink actually does to generate a solution is
> >> something like this:
> >>
> >> 1. Convert everything to be in the time domain (For example, transfer
> >> functions would need to be transformed).
> >> 2. Convert the graph to a state-space representation suitable for use
> >> with a RK-like method--that is, dx/dt = f(x) where x is a vector, and
> >> y = g(x), where y is a vector of all the things you want to put
> >> virtual O-scopes onto.
> >> 3. Apply an RK-like method to the state-space representation.
> >> 4. Profit!
> >>
> >> Matlab/Simulink give you lots of options for step (3), and this part
> >> can be looked up in any numerical methods textbook, so it's relatively
> >> easy to get a handle on. In fact, I'm sure scipy has RK methods in it
> >> somewhere if it can claim to be anywhere near complete. Similarly, I
> >> would hope part (1) to be fairly straightforward.  The part that I
> >> didn't have much luck on is step (2), but my guess is that you would
> >> have to traverse the graph and try to unroll any loops using rules
> >> specific to 'special' blocks, such as "1/s" blocks. I'm not sure it
> >> can get any more general than that.
> >
> > this sounds a bit what pylab works tries to do
> >
> > http://pic.flappie.nl/
> >
> http://mientki.ruhosting.nl/data_www/pylab_works/pw_animations_screenshots.html
> >
> > Compared to graphical programming (and UML and Excel), programming
> > directly in Python is a lot more fun and flexible in my opinion. There
> > isn't a whole lot of boiler plate code to automate away.
> >
> > Josef
> >
> >>
> >> My $0.02,
> >>
> >> --Josh
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev@scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev@scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20101116/dd96280c/attachment.html 


More information about the SciPy-Dev mailing list