The behavior you see for MinimalExample.example and MinimalLibrary.Example are bugs, and from what I can see they should work, I have forwarded them to a developer working on these things.

As for the validation of MinimalLibrary.Components.SimpleClock, what happens is that you have an outer component (outer constant String unitOfTime). The rules for inner/outer in Modelica (this was updated recently) is that an outer element requires that an inner element exists or can be created in a unique way. In this case, there exists no inner element, but a unique inner element can be created, by simply taking the outer declaration as it is (this is basically what the first warning says). The second warning appears because the constant has no binding (although I am not sure why it is referred to as a parameter).

We have recently implemented some support for setting the displayUnit for the x-axis in SimulationCenter, currently it only goes up to days, maybe we should see if we could add years as well. I guess you would like a way to specify this in the model so you don't have to change the plots all the time.

As for the parameters in the diagram view, I assume you are referring to things like this:

which seems to always use the unit. So, it would be better for you if it was displayed in the displayUnit, maybe with the displayUnit as well? So, in the picture above, it would read "J = 1.7 kgm^2", or if the displayUnit was changed to lb ft^2, it would say "J = 40.34 lb ft^2".

Carl,

that would indeed be a great help. At the moment I am simply reducing everything (using an enumeration called "UnitChoices") to:

• Dmnl ("1")
• Rate ("1/s")
• Time ("s")

Thinking about this from a model user's perspective: You would want to place a stock or a converter (Block) element somewhere and then assign a unit to its output (more tricky for complex sub-system elements with lots of different outputs, which rather call for bus-like output connectors - which would not be expandable per se ?).

That user-dialog has to be made "easy to use" (which is why I simply go for drop-down enumeration) and "reliable". If the user has to enter a string, say "apples/s", then there is some danger of a typo and everything breaks down.

Maybe with what you are saying one could come up with a mix: use a drop-down field to distinguish the choices like the ones listed above and additionally allow the user to overwrite the dimensionless part of the drop-down choice: "1". In that case, the user can choose a Rate and then the string "apple" or "apples".

Hope I have written this clearly?

Guido

PS: My understanding is, that what I have described for the user is the reverse procedure of what you will probably be doing, e.g. parse a string for "something/s" and then replace something -> 1?

Otto,

what about rates? Is there a remedy for the apples/second and oranges/second problem I mentioned above?

Thanks.

Guido

... continued from above

Inner/Outer with a simple constant

I am even more perplexed by the following. Let's simplify the above example, instead of using complicated type constructs, we might simply define a constant String UnitOfTime that will be set to provide the string-expression needed to define unit = "some unit" for a var in a sub-component. Again, that constant expression will be given the prefix inner (note, that we should not be needing replaceable here, as we may use simple modification instead).

Minimal Library

The "library" now only consists of a partial model GenericSimulationModel where the unit-string is defined and a very simple component SimpleClock that is to return the simulation time in the Non-SI-Unit chosen. Within that component we use the unit-string given as a global constant directly to configure the output y:

output Real y( final quantity = "Time", unit = UnitOfTime );

Here is the complete MinimalLibrary - code for this:

package MinimalLibrary "Example for setting a global unitString constant"

  package Interfaces "Partial models and connectors"

    partial model GenericSimulationModel "Top-level class defining global parameters for simulation model"
      inner constant String UnitOfTime = "yr";
    end GenericSimulationModel;

  end Interfaces;

  package Components

    block SimpleClock "Return the simulation time in Non-SI-Unit of time"
      outer constant String UnitOfTime;
      output Real y(final quantity = "Time", unit = UnitOfTime);
    equation
      y = time;
    end SimpleClock;

  end Components;

  model Example "Show a simple clock functionality"
    extends Interfaces.GenericSimulationModel( UnitOfTime = "mo");
    Components.SimpleClock clock;
  end Example;

end MinimalLibrary;

Errors and Warnings

Warning issued for missing start value for outer declaration

While the whole library code above validates sucessfully, there is a warning given when validating the SimpleClock in the Components package which honestly I do not understand:

System Modeler seems to issue a warning, because within the outer declaration there is no start value given? But that in my opinion is how you are supposed to write outer declarations. I will cite Peter Fritzon:

Outer class declarations should be defined using the short class definition. Modifiers to such outer class declarations are only allowed if the inner keyword is also present, i.e., a simultaneous inner outer class declaration.

The last point is illustrated by the following erroneous model:

class A 
  outer parameter Real p = 2; // Error, since declaration equation needs inner 
end A;

Fritzson, Peter. Principles of Object-Oriented Modeling and Simulation with Modelica 3.3: A Cyber-Physical Approach (Kindle-Positionen8875-8881). Wiley. Kindle-Version.

Error given when running the Example model in Simulation Center

Trying to run the model Example will not finish since the model compiles with an error:

Note: The error will arise also, when the modification (UnitOfTime = "mo") is removed.

After having learned, that we must use constants to set the unit attribute (here), I am rather perplexed to now find, that this will not work out when we use inner/outer declarations.

Is there something wrong with the way inner and outer are implemented?