RiverWare 6.1: Unit Schemes / 8-5-2011
Unit Scheme support for Data Objects
"riverwareDB" files DID support attribute matching rules for specific Slot Names on Data Objects. But the current development implementation of Unit Schemes does not.
[ See the RiverWare online documentation, "Units" section 3.6 "Data Objects" ... page 5: http://cadswes.colorado.edu/PDF/RiverWare/documentation/Units.pdf ]
The current Unit Scheme support for Data Object slot display attributes is limited to Unit Type matching rules. (We chose to not implement the full expressiveness of "riverwareDB" files, and specific Slot Names on Data Objects was one thing that I dropped out). It turns out, though, that custom configurations for specific Data Object slots is actually important. For one thing, Data Object slots are often used for aggregated results at a timestep size larger than the model timestep, e.g. for annual aggregations -- so different scaling and/or time denominators are often desirable for those slots.
I describe THREE options for implementing support for this requirement, in increasing order of development complexity:
The new Slot Name Chooser dialog currently enumerates the names of slots on the prototype Simulation Objects and prototype Accounts -- and the unit types used by those slots. The Unit Scheme Editor (see schematic) uses selections returned from this dialog box to construct Slot Name "matching rules" for a mapped unit scheme. Each such rule is associated with exactly one unit type. So, the illustrated selection (two rows) would result in the creation of five Slot Name rules specific to slots on Storage Reservoir having one of the two selected names: Minimum Release or Preliminary Data.
Unlike Engineering Object prototypes, the prototype Data Object doesn't have preconfigured slots. Only user-created Data Objects have slots.
We could enhance the Slot Name Chooser to enumerate also the names of slots on existing Data Objects in the current RiverWare model. Slots with the same name on distinct Data Objects would be aggregated as a single item, with a "union" of all the units represented on those slots.
It's as simple as that. Such slot name selections and the resulting "matching rules" wouldn't need to be handled differently by the Unit Scheme Editor or the UnitScheme::Key class.
The Slot Name Chooser could include a checkbox to enable the inclusion of Data Object slot names -- it might make sense to be able to keep those separate. (The enumeration of ONLY slots on Data Objects is implicitly supported with the existing object type combo box -- and frankly, in the current implementation, no slot name rows ever show up when "Data Object" is the selected item in that combo box).
(I think this would take 1.25 to 2.0 days of development work).
The decision to constrain slot names used in mapped Unit Scheme matching rules to the actual hard-coded names of Slots on Engineering Objects and the four Account Types isn't fundamental. And that design decision is a property of only the Slot Name Chooser dialog. That was an appropriate decision, I think, for those built-in slot entities because not only do the slot names need to be correct (which could be relaxed, e.g. case sensitivity could certainly be relaxed), but more importantly, slot names need to be paired with the actual unit types used on those slots -- and that's a lot to ask the user to "free hand".
But for the slots for which the user is responsible -- in control of their own slot naming convention, etc -- it would be reasonable to provide a "relaxed" method of providing slot name and unit pairs -- i.e. with a dialog box with a name entry field and unit type combo box.
Or, since Data Object slot name selection is, by definition, slot-instance based, the GUS slot selector could be used for selecting Data Object slot names (with unit types). (That wasn't an easy option for our Engineering Object and Account slots because GUS doesn't currently support selection of slots on the prototype objects. See early analysis).
In either of those cases (free entry or GUS selection), wildcarding of the slot name could be supported. Since users are in control of the slot naming scheme for slots on their data objects, a strategic use of wildcarding could work to greatly reduce the number of Unit Scheme matching rules needed for data object slots.
Other Details:
More analysis would be needed to venture a development estimate.
If the actual requirement for explicit slot name-specific support for slots on data objects is directly due to the difference in series timestep size (e.g. for time aggregation of model run results), a broader approach which could reduce the number of required matching rules for data objects, and would add useful expressiveness for physical slots to boot, would be to support distinct matching rules for the unit types having a "per-time" factor (e.g. Flow and Power) -- for each of the timestep sizes supported by RiverWare. (Yeah, I know, all unit types have a "per time" factor with respect to some other possible unit type, namely that unit type times time, but you know what I mean).
For example, there could be different scaling or time denominators for a FLOW in a daily series (without regard to slot name) and a FLOW in an annual timestep series (without regard to slot name).
This option is not actually exclusive to the prior options. But enough is enough.
The idea of "Series Timestep Size-Dependent Matching Rules" was explored in the original analysis document (section 3.1.1, page 6) -- albeit for a different motivation ... and explicitly dropped in the subsequent design document (section 5.2, page 10).
| NOTE: It may be useful to get our hands on some production versions of users' "riverwareDB" files to gain some insight into what they're up against, and the level of complexity-reduction each of these different approaches could actually provide. |
--- (end) ---
