Getting Physical¶

Physical Units¶

As mentioned already in this section, these examples are a bit more physical because they include individual physical parameters that correspond to individual properties of our real world system. However, we are still missing something. Although these variables represent physical quantities like temperature, mass, etc., we haven’t explicitly given them any physical types.

As you may have already guessed, the variable T is a temperature. This is made clear in the descriptive text associated with the variable. Furthermore, it doesn’t take a very deep analysis of our previous model to determine that T0 and T_inf must also be temperatures.

But what about the other variables like h or A? What do they represent? Even more important, are the equations physically consistent? By physically consistent, we mean that both sides of the equations have the same physical units (e.g., temperature, mass, power).

We could convey the physical units of the different variables more rigorously by actually including them in the variable declarations, like so:

model NewtonCoolingWithUnits "Cooling example with physical units"
  parameter Real T_inf(unit="K")=298.15 "Ambient temperature";
  parameter Real T0(unit="K")=363.15 "Initial temperature";
  parameter Real h(unit="W/(m2.K)")=0.7 "Convective cooling coefficient";
  parameter Real A(unit="m2")=1.0 "Surface area";
  parameter Real m(unit="kg")=0.1 "Mass of thermal capacitance";
  parameter Real c_p(unit="J/(K.kg)")=1.2 "Specific heat";

  Real T(unit="K") "Temperature";
initial equation
  T = T0 "Specify initial value for T";
equation
  m*c_p*der(T) = h*A*(T_inf-T) "Newton's law of cooling";
end NewtonCoolingWithUnits;

Note that each of the variable declarations now includes the text (unit="...") to associate a physical unit with the variable. What this additional text does is specify a value for the unit attribute associated with the variable. Attributes are special properties that each variable has. The set of attributes a variable can have depends on the type of the variable (this is discussed in more detail in the upcoming section on Variables).

At first glance, it may not seem obvious why specifying the unit attribute (e.g., (unit="K")) is any better than simply adding "Temperature" to the descriptive string following the variable. In fact, one might even argue it is worse because “Temperature” is more descriptive than just a single letter like “K”.

However, setting the unit attribute is actually a more formal approach for two reasons. The first reason is that the Modelica specification defines relationships for all the standard SI unit attributes (e.g., K, kg, m). This includes complex unit types that can be composed of other base units (e.g., N).

The other reason is that the Modelica specification also defines rules for how to compute the units of complex mathematical expressions. In this way, the Modelica specification defines everything that is necessary to unit check Modelica models for errors or physical inconsistencies. This is a big win for model developers because adding units not only makes the models clearer, it provides better diagnostics in the case of errors.

Physical Types¶

But truth be told, there is one drawback of the code for our NewtonCoolingWithUnits example and that is that we have to repeat the unit attribute specification for every variable. Furthermore, as mentioned previously, K isn’t nearly as descriptive as “Temperature”.

Fortunately, we have a simple solution to both problems because Modelica allows us to define derived types. So far, all the variables we have declared have been of type Real. The problem with Real is that it could be anything (e.g., a voltage, a current, a temperature). What we’d like to do is narrow things down a bit. This is where derived types come in. To see how to define derived types and then use them in declarations, consider the following example:

model NewtonCoolingWithTypes "Cooling example with physical types"
  // Types
  type Temperature=Real(unit="K", min=0);
  type ConvectionCoefficient=Real(unit="W/(m2.K)", min=0);
  type Area=Real(unit="m2", min=0);
  type Mass=Real(unit="kg", min=0);
  type SpecificHeat=Real(unit="J/(K.kg)", min=0);

  // Parameters
  parameter Temperature T_inf=298.15 "Ambient temperature";
  parameter Temperature T0=363.15 "Initial temperature";
  parameter ConvectionCoefficient h=0.7 "Convective cooling coefficient";
  parameter Area A=1.0 "Surface area";
  parameter Mass m=0.1 "Mass of thermal capacitance";
  parameter SpecificHeat c_p=1.2 "Specific heat";

  // Variables
  Temperature T "Temperature";
initial equation
  T = T0 "Specify initial value for T";
equation
  m*c_p*der(T) = h*A*(T_inf-T) "Newton's law of cooling";
end NewtonCoolingWithTypes;

You can read the definition type Temperature=Real(unit="K", min=0); as “Let us define a new type, Temperature, that is a specialization of the built-in type Real with physical units of Kelvin (K) and a minimum possible value of 0”.

From this example, we can see that once we define a physical type like Temperature, we can use it to declare multiple variables (e.g., T, T_inf and T0) without having to specify the unit or min attribute for each variable. Also, we get to use the familiar name Temperature instead of the SI unit, K. You might be wondering what other attributes are available when creating derived types. For further discussion, see the section on Built-In Types.

At this point, you might find the idea of defining Temperature, ConvectionCoefficient, SpecificHeat and Mass in every model extremely tedious. It would be, if it were truly necessary. But don’t worry, there is an easy solution to this as you will see in a later section where we discuss Importing Physical Types.