[GSoC] OpenModelica Integration Discussion

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

[GSoC] OpenModelica Integration Discussion

This post was updated on .
Hi all,


I made a preliminary proposal for the project I discussed on previous thread. So I'm asking for some comments about it, possible misconceptions, unfeasible time estimates, etc.

- Requirements

Here is the image showing compiled scilab-master initial screen and "about" window:


Apart from my patch for last GSoC, I'm also trying to push some Coverity fixes (more to come).


Thanks again.


Att,
Leonardo
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi, all.

I have tried some other coverity fixes and ended up submitting the proposal at GSoC page. There were no comments so I am assuming the text is mostly OK.

Thanks again.


Att,
Leonardo.
Caioc2 Caioc2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi,


It seems good for me, you have been discussing all those ideas with scilab team, and I think it is already well defined which incomes are expected for this project.
I would like a better detailed schedule, maybe less weeks but more details for each topic, but I also know that it is hard to give those details before working on them.

You could improve the document style, to make things you think to be important "pops out", but it would be just a lift up, irrelevant to its content.

On Sun, Apr 2, 2017 at 8:15 PM, Bitiquinho <[hidden email]> wrote:
Hi, all.

I have tried some other coverity fixes and ended up submitting the proposal
at GSoC page. There were no comments so I am assuming the text is mostly OK.

Thanks again.


Att,
Leonardo.



--
View this message in context: http://mailinglists.scilab.org/GSoC-OpenModelica-Integration-Proposal-draft-tp4036042p4036117.html
Sent from the Scilab / GSOC - Mailing Lists Archives mailing list archive at Nabble.com.
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc


_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi, Caio.

Thanks for your input. I'll try to address those points (at least some of them) before the submission deadline.


Att,
Leonardo.
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

In reply to this post by Bitiquinho
Hi All,


With a little delay, thanks for accepting me to participate in one more GSoC with Scilab !

As stated in my proposal, during the bonding period, I'll be looking into building a minimal OMC compiler inside Scilab's build system in place of the modelicac compiler, to get things started.

I hope I can contribute enough during this summer.


Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi all,

First of all, sorry for being a little late with getting started

I'll be posting my progress reports in the same blog I have used last year: http://bitiquinho.github.io/2017-05-12-google_summer_of_code_2/

The GSoC webpage says that my mentors this year are davidcl (Clément David, I suppose) and paro. I would like to know what are your preferred way of communicating for questions and other discussions.


Thanks again
paul paul
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft


Hello Bitiquinho,

Thank you for that. Email is our go-to tool, to keep traces, but for
punctual exchanges you may connect to our IRC
(https://www.scilab.org/fr/resources/user_community/irc)

Regards,
Paul (paro)

On 2017-05-12 06:38, Bitiquinho wrote:

> Hi all,
>
> First of all, sorry for being a little late with getting started
>
> I'll be posting my progress reports in the same blog I have used last
> year:
> http://bitiquinho.github.io/2017-05-12-google_summer_of_code_2/
>
> The GSoC webpage says that my mentors this year are davidcl (Clément
> David,
> I suppose) and paro. I would like to know what are your preferred way
> of
> communicating for questions and other discussions.
>
>
> Thanks again
>
>
>
>
> --
> View this message in context:
> http://mailinglists.scilab.org/GSoC-OpenModelica-Integration-Proposal-draft-tp4036042p4036372.html
> Sent from the Scilab / GSOC - Mailing Lists Archives mailing list
> archive at Nabble.com.
> _______________________________________________
> gsoc mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/gsoc
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Bitiquinho
Hi all,

I was revisiting my discussion for this project that I had with Clément before submitting my proposal, and I came across this:

"You can split the tasks as :
 1. build a simple OMCompiler
 2. get into the code to discover how to generate FMI2 API (or internal API)
 3. write a scicos_block4 compatible block generator (either using a wrapper or a new code
generator)
 4. package everything for all Scilab supported platforms (in thirdparties)."

So, about task 4: I almost went for figuring out a way to build a simple OMCompiler as part of the Scilab build itself (like what happens with modelicac compiler), but that didn't make much sense, as OpenModelica is a full application that could be installed/packaged by distributions separately. I guess that OMCompiler would be more like a soft dependency during Scilab compilation, whose detection triggers the building of compatible scicos_block4 generator. That's why it would be stored inside thirdparties folder, right ?

However, currently the thirdparties SVN repository seems to only contain Java Jar packages. How should I add a new C++ target to its building process ? Or are the packages for this repo just copied from their respective binary releases ?

Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

(I don't know if someone saw my question here or in the mailing list, but I'm really clueless about the thirdparties repo)

Hi again

I spend some time over the last days trying to understand how Xcos model compilation calls the Modelica compiler, and it seems like everything comes down to the build_modelica_block function (inside modules/scicos/macros/build_modelica_block.sci), which separates the process in combining all Modelica into a single .mo file (inside create_modelica) and feeding this to actual translation (which I don't quite get what means), compilation (modelicac calling), properties aquisition (reading_incidence) and linking (all inside compile_modelica function)

Is that accurate ? I couldn't find any other reference to modelicac executable being called.

Could I assume that the code generated by create_modelica is completely standard (even if outdated) and one wouldn't have any issues passing it to a different compiler, so that I could just leave this function as it is ?

If the usage of OMCompiler (rather than modelicac) will be conditional, what is the proper way to change *.sci scripts during Scilab build process ? Or should the Modelica compiler be selectable with a runtime switch ?


Thanks again
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hello Leonardo,

(answered inline)

> Hi again
>
> I spend some time over the last days trying to understand how Xcos model
> compilation calls the Modelica compiler, and it seems like everything comes
> down to the build_modelica_block function (inside
> modules/scicos/macros/build_modelica_block.sci), which separates the process
> in combining all Modelica into a single .mo file (inside create_modelica)
> and feeding this to actual translation (which I don't quite get what means),
> compilation (modelicac calling), properties aquisition (reading_incidence)
> and linking (all inside compile_modelica function)
>
> Is that accurate ? I couldn't find any other reference to modelicac
> executable being called.

Yep this is all good ! There is also an XML file generation for tuning default values on do_eval ;
at first this is not critical but I am not sure if we can have such an output from OpenModelica.

About "translating", this is the process of flattening the Modelica class-like model to a single 1
file with a reduced syntax : eg. without "connect" or model inheritance.

> Could I assume that the code generated by create_modelica is completely
> standard (even if outdated) and one wouldn't have any issues passing it to a
> different compiler, so that I could just leave this function as it is ?

Yes it is, the code generated using create_modelica() is extracted from block parameters and is
standard ; the associated Modelica libraries are stored in `modules/scicos_blocks` :

modules/scicos_blocks/macros/Electrical/Electrical.mo
modules/scicos_blocks/macros/Hydraulics/Hydraulics.mo

> If the usage of OMCompiler (rather than modelicac) will be conditional, what
> is the proper way to change *.sci scripts during Scilab build process ? Or
> should the Modelica compiler be selectable with a runtime switch ?

IMHO the OMCOmpiler should be used instead of modelicac . The modelicac support is already optional
and OMCompiler can be embedded within Scilab dependencies. In the build process, you should not add
anything more ; just detect OMCompiler and use it.

Thanks,

--
Clément
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Bitiquinho
Hello Leonardo,

Exactly I missed this part, sorry :)

> However, currently the thirdparties SVN repository seems to only contain
> Java Jar packages. How should I add a new C++ target to its building process
> ? Or are the packages for this repo just copied from their respective binary
> releases ?

The SVN pre-requirements repository also contains binary : JVM, lib, etc.. The binary building is
not committed on the main repo ; there is a bash script for Linux thirdparties committed on the repo
to download and build them all. Visual Studio Projects are committed on another repo.

As OpenModelica have a lot of dependency, I suggest you to build a "minimal" version and use it. You
might also add a Scilab Preferences setting to let the user configure an external executable.

Thanks,

--
Clément
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Thanks for replying and sorry for the delay

Where could I find and edit the bash script and VS project files to add OMCompiler-minimal download and compilation to both pre-requirements repositories ?


Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Clément David-3
>Yep this is all good ! There is also an XML file generation for tuning default values on do_eval ;
>at first this is not critical but I am not sure if we can have such an output from OpenModelica.

Aside from C/C++ source code, OMCompiler also generates a modelDescription.xml file, but I'm not sure it can be used for the same purpose (looks like only a listing of state variables)

>IMHO the OMCOmpiler should be used instead of modelicac . The modelicac support is already optional
>and OMCompiler can be embedded within Scilab dependencies. In the build process, you should not add
>anything more ; just detect OMCompiler and use it.

But should modelicac still work as a fallback (in the absence of OMCompiler e.g. for Scilab packaged by distros) when building with Modelica support ? Or just ditched altogether ?


Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

This post was updated on .
In reply to this post by Clément David-3
Hi all,

I need to ask one more thing:

Looking at C code files produced by modelicac, I see that they include scicos_block.h instead of scicos_block4.h for scicos_block structure definition. Also, they use Get_Jacobian_parameter() function for Jacobian calculation, which is not declared in scicos_block4.h. There are Get_Jacobian_cj() and Get_Jacobian_ci() functions that I guess could be used in this case, but they don't seem to be implemented anywhere.

So, which header file should I use for a FMI2 wrapper implementation ?

Thanks in advance
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Bitiquinho
Hi again,

I have one more question:

According to Scicos Block documentation, DerivativeState (and I guess Jacobian also, but it's not listed) jobs for computational function use xd field of scicos_block structure as output, but when I was looking at the code generated by current Modelica compiler, that didn't seem to be the case:

void BouncingBall_Modelica_im(scicos_block *block, int flag)
{
        double *rpar = block->rpar;
        double *x = block->x;
        double *xd = block->xd;
        double *res = block->res;

        /* Intermediate variables */
        double v0;

        if (flag == DerivativeState) {
                res[0] = xd[0]-x[1];
                res[1] = rpar[0]+xd[1];
        }
        /* ... */
        else if (flag == Jacobian) {
                v0 = Get_Jacobian_parameter();
                res[0] = v0;
                res[1] = 0.0;
                res[2] = -1.0;
                res[3] = v0;
                res[4] = 1.0;
                res[5] = 0.0;
                res[6] = 0.0;
                res[7] = 1.0;
                set_block_error(0);
        }

        return;
}
 
The document I referenced states that the res array field has the same length as x and xd and is only used for internally implicit blocks, but its purpose is not clear. What is the difference between using res and xd ? Are the docs outdated ?
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hello Leonardo,

It seems that you are getting in-depth understanding of ODE vs IDA simulation :) . For related
papers, do not hesitate to take a look at the Sundials documentation.

Basically, a block perform a simulation in different domains and have outputs (or states) for all
the domains. For example, to compute an output with a continuous state your block performs:

 u = f(u, x, t)

To compute the derivative, it performs:

 xd = f(u, x, t)

That's it for pure continuous simulation but as Xcos performs in an hybrid mode where the simulation
is continuous between events there is an additional function to compute. The continuous system have
to be initialized after each event to check when block computation modes changed. This is called
"Jacobian" computation or residuals resolution and is performed using Sundials Kinsol solver.

To compute the residuals [2] (partial derivative of xd), this 0D (time constant) evaluation invoke
the blocks which computes:

 res = f(jac) where res is the residuals and jac is a value returned by the Kinsol solver.

[1]: https://en.wikipedia.org/wiki/Jacobian_matrix_and_determinant
[2]: https://en.wikipedia.org/wiki/Residual

Thanks,

--
Clément

Le vendredi 16 juin 2017 à 17:25 -0700, Bitiquinho a écrit :

> Hi again,
>
> I have one more question:
>
> According to  Scicos Block documentation
> <http://www.scicos.org/Newblock.pdf>  , *DerivativeState* (and I guess
> *Jacobian* also, but it's not listed) jobs for computational function use
> *xd* field of *scicos_block* structure as output, but when I was looking at
> the code generated by current Modelica compiler, that didn't seem to be the
> case:
>
> void BouncingBall_Modelica_im(scicos_block *block, int flag)
> {
> double *rpar = block->rpar;
> double *x = block->x;
> double *xd = block->xd;
> double *res = block->res;
>
> /* Intermediate variables */
> double v0;
>
> if (flag == DerivativeState) {
> res[0] = xd[0]-x[1];
> res[1] = rpar[0]+xd[1];
> } 
>         /* ... */
> else if (flag == Jacobian) {
> v0 = Get_Jacobian_parameter();
> res[0] = v0;
> res[1] = 0.0;
> res[2] = -1.0;
> res[3] = v0;
> res[4] = 1.0;
> res[5] = 0.0;
> res[6] = 0.0;
> res[7] = 1.0;
> set_block_error(0);
> }
>
> return;
> }
>  
> The document I referenced states that the *res* array field has the same
> length as *x* and *xd* and is only used for internally implicit blocks, but
> its purpose is not clear. What is the difference between using *res* and
> *xd* ? Are the docs outdated ?
>
>
>
> --
> View this message in context: http://mailinglists.scilab.org/GSoC-OpenModelica-Integration-Discuss
> ion-tp4036042p4036585.html
> Sent from the Scilab / GSOC - Mailing Lists Archives mailing list archive at Nabble.com.
> _______________________________________________
> gsoc mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/gsoc
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Loading...