CODEWITHSUNDEEP
modelicaopenmodelicadymolasystemmodelergraphical-interaction
janpeter
janpeter

Reputation: 1084

Gap GUI and code configuration for parametrised packages?

It is very practical to parametrise packages to improve reusability of code and a central theme of Modelica. The language support since long time back to also use types like packages and models as parameters for packages. The concept is sometimes called "type formal parameter" and described in Fritzson's book (2015) section 4.4 and related to Modelica specification section 7.

I have recently found it difficult to use GUI in OpenModelica to handle this parametrisation of packages, and first contacts indicates that also Dymola and Impact have similar shortcomings. It all boils down to how "class extends" is handled by the GUI. The code example below illustrate the problem together with the screenshot of the GUI further down.

 package DEMO_v80

     partial package MediumBase
        constant Integer nc = 0;
         replaceable type C = Real[nc];     
     end MediumBase;

     import Modelica.Blocks.Interfaces.RealInput;
     import Modelica.Blocks.Interfaces.RealOutput;

     package A_generic
         replaceable package Medium = MediumBase
             constrainedby MediumBase;

         model M1
             RealInput u;
             Medium.C c (each start=1, each fixed=true);
         equation
             for i in 1:Medium.nc loop
                 der(c[i]) = u*c[i];
             end for;
         end M1;
    
         model M2
             RealOutput y;
         equation
             y = -1;
         end M2;    
     end A_generic;

     package Medium2
         import DEMO_v80.MediumBase;
         extends MediumBase(nc=2);
     end Medium2;

     package A  
         import DEMO_v80.A_generic;
         extends A_generic(redeclare package Medium = Medium2);
     end A;

    model TEST
         A.M1 m1;
         A.M2 m2;
     equation
         connect(m2.y, m1.u);
     end TEST;  

 end DEMO_v80;

A screenshot of the OpenModelica library below shows that the package A_generic can be expanded while the specialised package A can not. I wish I could from A drag out models M1 and M2 and connect them instead of making the configuration by coding as in model TEST.

enter image description here

I can understand that the GUI should protect the package A from change of value of the the formal parameter, just given in the code. But It does not make sense to protect from access to the content of package A, i.e. model M1 and M2.

Is here some other way to implement the desired reusability of the code?

(And I want that all models in A_generic get the Medium by the value of the formal parameter).

Is this a problem not only for OpenModelica but also for Dymola, Impact etc?

Can perhaps someone briefly outline why GUI is difficult to implement the way I wish?

Note: This "gap" talked about here should be seen as a design-choice rather than a bug (and not very well documented for the user). I have some dialogue with people related to the different software discussed.

Upvotes: 0

Views: 107

Answers (2)

janpeter
janpeter

Reputation: 1084

Inspired by the Dymola example I took the effort to try Wolfram SystemModeler and that works also fine.

enter image description here

And dragging the specialised M1 into a new model TEST_new also worked like in Dymola.

enter image description here

If we do it properly, and make DEMO_v81 as a copy of _v80, introduce icons for M1 and M2 and drag the specialised components to a new model TEST_new_GUI and connect them, we get as expected

enter image description here

Let us try to find what Medium we have by using the GUI. First choose the configured system TEST_new_GUI, but we do not get any information. Perhaps expected, since Medium get a value in A and not in the configured system.

enter image description here

Let us instead choose A and take the same "class window" and then we see that Medium=Medium2. Note, the canvas is blank since we have not associated any icon to the package A.

enter image description here

In practice we would give package A a descriptive name, something like "package of components involved with media". That would make it much easier to select that package to get information about the media used.

Upvotes: 0

Hans Olsson
Hans Olsson

Reputation: 12517

It works as you wish in Dymola (at least since Dymola 2016 FD01).

Dymola's package browser for the example

And dragging that M1 into the new model M gives (apart from annotations):

model M
  DEMO_v80.A.M1 m1_1;
end M;

Upvotes: 2

Related Questions