RiverWare 6.3: Mass Balance Summary support for Salinity / Mass Units
Proposal / 5-11-2012 (a) / Phil Weinstein, CADSWES -- PDF

(0.1) Prior Documents

• Original Development Project Index
• URGWOM sample data set
• "Version 1" Feature Document (PDF)

(1.0) Existing Functionality (RiverWare 6.2)

Mass Balance Summary Slots in RiverWare currently support computations using Flow or Volume series slots as input terms to be summed. The user can currently include series slots with other unit types, but the recomputation reports an error. The following screenshots demonstrate the results of including Mass slots in a Mass Balance Summary:

Note: In the current implementation, if the set of referenced slots in a Mass Balance Summary includes unit types other than Flow and Volume, the option to hide the "Units" column is disabled, and that column is unconditionally shown.

(2.0) Proposal: Autodetection of Homogeneous Mass Units

One possibility is that the Mass Balance Summary could automatically detect that all of the series slots included in a Mass Balance Summary happen to all have Mass units, and effect the following changes:

1. The "Flow / Volume" toggle push button is changed to show "Mass", and is not operable.
2. The combo box to the right of that button is populated with the configured Mass units (depending on the Units file), typically:
   • g, kg, mg, metric_tons, tons.
3. The values of the referenced Mass slots would be shown in the currently selected Mass unit (e.g. tons).
4. "Water Balance" is replaced with "Mass Balance", wherever that term appears in the GUI.
5. The summation computation is supported, as expected, resulting in computed summation slots having Mass units.

Notes:

• All supported Mass slots (at least those that are instantiated in the crssShortageDEIS regression test) seem to be of the "dynamic flow" type, i.e. total amount of mass in motion (flowing) over a timestep duration. There doesn't seem to any "static amount" type of Mass, e.g. total amount of salt in a reservoir at the end of each timestep. This wouldn't be a big deal though: if there were such an entity, a Series RPL Expression slot would be needed to compute a "change in mass" series for that entity ([t] - [t-1]).

(2.1) Alternative Proposal: Autodetection of Any Homogeneous Unit Type

It would be a simple matter to support any single unit type in this way -- or a prescribed set of unit types. Probably even in the latter case, users would have to use some discretion in insuring that the computed sum is meaningful.

In the GUI, "Mass Balance" (e.g. in the title bar) would be changed to refer to the effective unit type, e.g. "Energy Balance Summary". Furthermore, we might want to change references to "Mass Balance Summary" in other parts of the GUI (and RiverWare documentation) to simply "Balance Summary".

For reference, here are the unit types currently supported in RiverWare 6.2:

Beyond the scope of this task, in the future we may want to support common unit-type pairs related by a "per-time" factor (as are Flow and Volume) such as the following pairs of related units:

• Power and Energy
• Velocity* and Length

(The reason a "per-time" factor is relevant here is that all quantities are represented in the context of a time series (a series slot), where the absolute number of seconds in each timestep is known, though sometimes variable, i.e. in the case of monthly or annual timesteps).

*In RiverWare, "Velocity" is a scalar value, not a directional vector (i.e. more correctly, "Speed").
---