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

[Joshua Holbrook]

> 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 at gmail.com> wrote:
> On Tue, Nov 16, 2010 at 12:29 PM, Joshua Holbrook
> <josh.holbrook at gmail.com> wrote:
>> On Tue, Nov 16, 2010 at 2:48 AM, burley <burley at 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 at 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 at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>