Automatic unit and property conversion in spark

In object based models, conversion becomes necessary when there is a mismatch among the representations of same physical quantity at the ports of different objects that need to be connected. The simplest example of this is with regard to physical units of measure, such as temperature. A more complex situation, but with the same character, is with regard to fluid flow, where the state can be represented in terms of any pair of independent properties, and the flow rate can be expressed volumetrically or in terms of mass. In HVAC applications, the most common example is moist air where properties and flow rate can be represented by temperature, relative humidity and volumetric flow, or by enthalpy, humidity ratio and mass flow rate, or other combinations. The need to connect objects with such disparate interfaces arises whenever system model developers following different conventions attempt to share models.
Customarily, conversion is done in an ad hoc manner, introducing conversion objects here and there in the problem, as needed. A somewhat more structured approach is to rigidly enforce a common set of units among all classes within a particular application-area library; this approach is recommended for the Neutral Model Format (NMF) (Bring, Sahlin et al. 1992). With this approach one can either undertake “hard conversion” of the underlying equations and re-implement the model, or take the easier path of “wrapping” the offending objects in new “macro objects” with needed converters. Neither choice is very attractive. The first is labor intensive, and errors may be introduced into sound code, while the second can lead to many unnecessary conversion, complicating the model and compromising run-time efficiency. In this paper we show a unified approach to automatic interface matching that does not suffer the above disadvantages. Special automatic conversion links, or “autolinks,” are introduced for this purpose. An autolink carries all admissible representations of one or more variables plus a set of conversion objects that represent constraints that need to be enforced among them. Herein we show that this approach is easily implemented, makes use of existing models with diverse units or properties at the interface, and produces optimum run-time efficiency. The idea of autolinks has been mentioned before in the literature. Kolsaker and Sahlin make essentially the same suggestion (Sahlin, Bring et al. 1995), but limit their discussion to “property links” only. Sowell and Moshier independently develop the concept, discussing it in terms of unit matching as well as fluid flow and properties. They also introduce the idea of automatic elimination of unneeded conversion objects before run-time by “pruning” the computation graph (Sowell and Moshier 1995). In the following, we expand upon the previous work, using examples to clarify the approach, and show the first implementation in the context of the current features of the Simulation Problem Analysis and Research Kernel (SPARK). We then suggest future extensions to made problem specification with autolinks more intuitive.