[gsoc] Simulink import

[Clément DAVID]

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.