Quantcast

Simulink import

classic Classic list List threaded Threaded
5 messages Options
xendo xendo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Simulink import

Hi,
I was thinking about developing Scilab -> Xcos translator as GSoC
project. Unfortunately the wiki page on this idea is empty. So maybe I
will describe the idea in a few words. I think it can be a good first
step to create my proposal .

The main aim of this idea is to create module(?), that will allow user
to import model from simulink (mdl) files to Xcos (xcos file). This
can be done in 3 main steps:

- creating simulink file parser. (Is the C/C++ obligatory? this look
really easy using  Pyparsing
http://www.fauskes.net/nb/parsing-simulink/ )

- reformating parsed data into .xcos (this is the hardest and most
time consuming part I think. There is a lot of Xcos blocks, new
toolboxes for Xcos can show up (that already exist in simulink) so it
should be fairly easy to create a simulink -> xcos 'migration' schema
for new toolboxes etc.

- testing! After GSoC the Simulink import function should be usable
for most users. But I think that even after GSoC ends, I will be able
to maintain this module and kill some bugs from time to time.

There is a lot of work ahead of me to prepare good propoal, that's why
I really count on your suggestions!

Clément DAVID Clément DAVID
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulink import

Hi,

> Hi,
> I was thinking about developing Scilab -> Xcos translator as GSoC
> project. Unfortunately the wiki page on this idea is empty. So maybe I
> will describe the idea in a few words. I think it can be a good first
> step to create my proposal .
>
> The main aim of this idea is to create module(?), that will allow user
> to import model from simulink (mdl) files to Xcos (xcos file). This
> can be done in 3 main steps:
>
> - creating simulink file parser. (Is the C/C++ obligatory? this look
> really easy using  Pyparsing
> http://www.fauskes.net/nb/parsing-simulink/ )

You can also take a look at
http://conqat.cs.tum.edu/index.php/Simulink_Library which is a java
implementation of an MDL parser.

Another way is to start writing a new parser but be careful about the
MDL format as The Mathworks says that the format may change in the
future
[http://www.mathworks.com/access/helpdesk/help/toolbox/simulink/slref/f22-7548.html].

> - reformating parsed data into .xcos (this is the hardest and most
> time consuming part I think. There is a lot of Xcos blocks, new
> toolboxes for Xcos can show up (that already exist in simulink) so it
> should be fairly easy to create a simulink -> xcos 'migration' schema
> for new toolboxes etc.
> - testing! After GSoC the Simulink import function should be usable
> for most users. But I think that even after GSoC ends, I will be able
> to maintain this module and kill some bugs from time to time.
>

Right approach there. I suppose that some Simulink evaluation functions
differs on Xcos/Scicos and others may not be  present. For the latest,
they can be easily implemented on Xcos but for the GSoC it may not be
easy to implement them all.

At the end of the GSoC, we wish to have a working infrastructure with
compatibility matrix and limitation highlighting.

> There is a lot of work ahead of me to prepare good propoal, that's why
> I really count on your suggestions!

I will update the wiki page soon.

Thanks for your interest.

--
Clément DAVID (davidcl)


xendo xendo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulink import

Before writing a draft of my proposal I would like to make sure I'm on
the right way. So I will mix your wiki entry with my ideas:

1. Parse the MDL file and reconstruct an equivalent diagram.
There are already solutions to that part of the project, they need a
closer look and analysis of potential usage. Efficiency should not be
problem in here, but we have to be careful and avoid unnecessary
dependencies. So maybe rewriting parser in C++ will be the best idea.
All of this should be decided during Community bonding period.

2. Implement some compatibility patterns for evaluation functions and
block representations.
Here my idea is to create XML files containing migration schema. XML
will be clean, easy editable solution. Each Xcos part will have it's
own compatibility pattern file (separate files for general parameters,
mathematical operations, thermo-hydraulics and so on), adding simulink
import capabilities to your own custom palette will require writing
XML file describing differences with it's simulink counterpart. The
simulink functions will be mapped on xcos functions by those xml files
using C++ module. It would be great if those compatibility patterns
allowed (of course after writing suitable module) also simulink
export.

3. Validate the approach by evaluating diagrams compatibility.
It's important to create clean log files from each import attempt as
early as possible. It will make community feedback possible, and
testing during development much easier. It can be very hard to
automatically evaluate simulation results, even if import is
successful the outcome may differ (sometimes it could be caused by
different solver construction, numerical errors, and sometimes by
import error...). Here I have question, should the automatic
verification of the correctness be the part of the import
functionality?

I've read the How to apply to the GSOC wiki entry, but I'm not sure
how big should my proposal be. In description of the technical
solution part you wrote that "The more, the better.", should I prepare
some examples of c++ code, or xml file structure?

P.S.
sory for my english, it's not as fluent as I would like it to be, but
I hope it won't be a problem.

Clément DAVID Clément DAVID
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulink import

Hi,

> Before writing a draft of my proposal I would like to make sure I'm on
> the right way. So I will mix your wiki entry with my ideas:
please do :) . The wiki is only a list of ideas. We will choose the
right thing to do when reading your proposal.

>
> 1. Parse the MDL file and reconstruct an equivalent diagram.
> There are already solutions to that part of the project, they need a
> closer look and analysis of potential usage. Efficiency should not be
> problem in here, but we have to be careful and avoid unnecessary
> dependencies. So maybe rewriting parser in C++ will be the best idea.
> All of this should be decided during Community bonding period.

Do not hesitate to add these planning issues into your proposal.

>
> 2. Implement some compatibility patterns for evaluation functions and
> block representations.
> Here my idea is to create XML files containing migration schema. XML
> will be clean, easy editable solution. Each Xcos part will have it's
> own compatibility pattern file (separate files for general parameters,
> mathematical operations, thermo-hydraulics and so on), adding simulink
> import capabilities to your own custom palette will require writing
> XML file describing differences with it's simulink counterpart. The
> simulink functions will be mapped on xcos functions by those xml files
> using C++ module. It would be great if those compatibility patterns
> allowed (of course after writing suitable module) also simulink
> export.

Of course it may be better but in some case it may be time-consuming to
write compatibility patterns from Xcos to Simulink, maybe a future
evolution.

>
> 3. Validate the approach by evaluating diagrams compatibility.
> It's important to create clean log files from each import attempt as
> early as possible. It will make community feedback possible, and
> testing during development much easier. It can be very hard to
> automatically evaluate simulation results, even if import is
> successful the outcome may differ (sometimes it could be caused by
> different solver construction, numerical errors, and sometimes by
> import error...). Here I have question, should the automatic
> verification of the correctness be the part of the import
> functionality?

I don't think so, we can easily start a diagram compilation after the
import but it may be optional.

>
> I've read the How to apply to the GSOC wiki entry, but I'm not sure
> how big should my proposal be. In description of the technical
> solution part you wrote that "The more, the better.", should I prepare
> some examples of c++ code, or xml file structure?

This importer is really a non-trivial task, I think that you may begin
playing with Scilab ASAP. As said in the requirements, you can start
compiling Scilab, playing and submit a patch for a bug.

Have you read the Gsoc FAQ ? There is a good proposal description
there :
[http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_app]

>
> P.S.
> sory for my english, it's not as fluent as I would like it to be, but
> I hope it won't be a problem.
Your english is ok for me.



sylvestre sylvestre
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulink import

Le lundi 29 mars 2010 à 10:24 +0200, Clément DAVID a écrit :
> Hi,
>
> > Before writing a draft of my proposal I would like to make sure I'm on
> > the right way. So I will mix your wiki entry with my ideas:
> please do :) . The wiki is only a list of ideas. We will choose the
> right thing to do when reading your proposal.

By the way, I'd like to highlight that this development should include
unitary tests at the end of the project. It should be trivial to do.

> >
> > I've read the How to apply to the GSOC wiki entry, but I'm not sure
> > how big should my proposal be. In description of the technical
> > solution part you wrote that "The more, the better.", should I prepare
> > some examples of c++ code, or xml file structure?
>
> This importer is really a non-trivial task, I think that you may begin
> playing with Scilab ASAP. As said in the requirements, you can start
> compiling Scilab, playing and submit a patch for a bug.
> Have you read the Gsoc FAQ ? There is a good proposal description
> there :
> [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_app]
There is also our requirements listed here:
http://wiki.scilab.org/How_to_apply_to_the_GSOC_%3F

Sylvestre



Loading...