Mass Balance Summaries in RiverWare 6.2 -- Dec 2011 / Jan 2012
Project index ... Review of the 12-30-2011 Design Document / PDF, 18 pages.

David's review (1-1-2012) and Phil's responses (1-2-2012) / additional note (1-3-2012)

1 The mass balance summary name should somehow include the data object name on which it lives, especially from the Workspace menus.
  Yes. Actually, given that mass balance summaries are being deployed only on data objects (only one per data object), I wasn't planning on presenting a distinct name for "summaries". The displayed name IS the name of the data object. (In my examples, the data object name is "MassBalOne" ... shown next to a data object icon button).
2 In this current design, can you have just 2 or 3 levels instead of requiring 4? I think 2 or 3 groups would be more useful for other models and perhaps even URGWOM.
 

I'm not sure that complicating the design to support a varying number of levels results in something easier to understand and use. We would probably not want to "name" the levels in a "varying-level" design. But having explicitly named levels provides a way of talking about the configuration, and probably typically results in a cleaner user configuration definition. If a user doesn't need 4 levels, it's not a big deal to have a single instance of a top-level item.

Probably URGWOM would use only three levels if the mass balance summaries remain were distributed to SIX data objects -- i.e. one mass balance summary on each of six data objects. (Note: the URGWOM Rpl expression slot implementation uses 17 data objects, so six would represent a consolidation -- SEE ADDITIONAL NOTE BELOW). If that's preferable, maybe we should just go to three levels (and demonstrate this using six summaries on six data objects). They may or may not prefer seeing the mass balance summary data all in one place.
3 The "Dependent Expression Slots" list seems like a new concept. Do we really need this now?
  Is there some other way of automatically implementing a dependency-related auto-reevalutation of Rpl expression slots? If not, this sort of device is really easy to implement: a list of slots to be evaluated after the mass balance summary is recomputed. It's also nice to have a place for the user to explicitly indicate which slots are part of the mass balance calculation (i.e. the small set of slots computed from it).
4 I thought we were getting rid of the min and max columns? It is misleading. Is it the min/max of the slots at that timestep or across all timesteps? If we are going to optionally show them, there should be an obvious control on the gui.
 
 

My original presentation (in an early screenshot) was confusing because I showed different "precisions" for the value column and min/max columns. I fixed that, and hope we can take a look at this again. I'm recommending that the min / max columns (upper and lower bounds of each series) be shown conditionally, based on a checked item in the "View" menu (see image).

The displayed min and max values are across all timesteps in the time series represented in each row. I understand that, on first glance, potential confusion with another possible interpretation is possible, but that doesn't negate the value of showing these as a summary of the computed series -- especially for "balance" series which are expected to be approximately zero on all timesteps.

Even for series which aren't supposed to be approximately zero, showing where the current (at the indicated timestep) value falls within the series' range of values can give some context for that value -- i.e. whether or not it is near one of the extreme values of the slot.

Showing summation values at only one timestep doesn't make this much of a "summary" display. If we do that, I'd call this dialog a Summary Configuration dialog. The actual "Summary" display would be a generated SCT or plot page. (But I was hoping that one dialog could function both for configuration AND a brief summary).
5 Instead of "values", perhaps "Show Sum" for the sums and "Show Values" for the slots.
 

I tried moving the "values" checkboxes to checked items in the "View" menu. (We could play with the actual item text). (This would be instead of having them with the level legend buttons, see below):

See full dialog screenshots:  one .. two

    

revised "View" menu
6 What are abbreviation columns? Expand on this or show mockup.
  The "abbreviation column" is an optional display column in the main tree view. Any of the collection items (top three levels) can be given an abbreviation to be used in the composition of the sum slot name for that collection item. (See this example of typical names not using abbreviations; of course, the names of each of the collections could be made shorter). The abbreviation would be typed right in the cell in the tree view (i.e. in the abbreviation column, when that column is shown).
7 Slot Generation names: Why "mb_"?  Also, what is the rest of the name going to be?
 

I suggest we recommend a simple prefix -- it doesn't have to be "mb_". (That was for "mass balance"). Here is a list of sample generated names -- this shows the "mb_" prefix and the different name parts separated with an underscore.

Below is an example of one of the longer slot names, not using any abbreviations. "MassBalOne" is the data object. "SanAcaciaToSanMarcial Budgets" is the Water Balance Group. "River Reach Budget" is the Water Balance. "CanalInflowFromAbove" is the Slot Group.

MassBalOne.mb_SanAcaciaToSanMarcial Budgets_River Reach Budget.CanalInflowFromAbove
8 The Mass Balance Slot Group Configuration Dialog seems unintuitive. Shouldn't you pick the objects first, then choose which Slot Group, then pick slots?  At least, shouldn't the "available slots" and selected slot panels be switched. That is, the user would move the slots from the avail list on the left to the area on the right.
  Actually the arrangement of the four panels ("quadrants") well represents the relationships between them. The upper left is the main selection, showing what is being edited. (Knowing what is being edited "comes first"). Each of the two bottom panels effectively show "content" of the selection in the panels above each of them. The two left panels show what is being edited (the Slot Group and it's contained slots). The two right quadrants indicate what the potential slots are: what objects they come from (top) and what the slots are (bottom). Selecting items in each of the top panels dynamically populates the panel below it (and it would be strange if that effect appeared in the diagonally opposite panel). Starting from an empty definition, the only two active buttons will be "Add ..." (in the object filter) and "Close". I think, in actual use, it will quickly become clear.
9 Separate export/import is not needed as there is export/import of the object and copy/paste within the model.
  Yes, I agree. I'll remove those. In fact, I've been using an exported SimObj (with a mass balance summary) to hold my test data.
10 The four colored buttons at the top only open that level, right? They seem big for just that purpose. They could just be little toolbar buttons with associated menus. Move the count and the "values" to the configure panel.
  See images above, in item 5. I like that the "level" buttons function as a color key as well as a quick way to open the tree view up to each level -- actually very useful. They are a little wide to put into a single row, unless we change "Water Balance / Groups" to something shorter, or change to just three levels (instead of four). If we don't want to retain the color associations, we could put these functions in the "View" menu.

Additional Note (1-03-2012): Followup on number of "levels" (four? -- or fewer?) and the URGWOM reference model.

In my comments on #2, I mistakenly stated that URGWOM distributed their mass balance computations among 6 data objects -- one for each "Water Balance Group".  Actually they have a distinct Data Object for each "Water Balance" (with two exceptions) -- apparently 17 data objects;  plus another data object for annualizations.  (David pretty much correctly described this in the initial 2-pager).

Here is a list of their top-level mass balance RPL expressions, most of which are on their own data object ... 

BernardoToSanAcacia Canal Budget.Canal SW Budget
BernardoToSanAcacia GW Budget.GW Budget
BernardoToSanAcacia River Budget.River SW Budget

CentralToIsleta GW Budget.GW Budget
CentralToIsleta River Budget.River SW Budget

CochitiToSanFelipe Canal Budget.Canal SW Budget
CochitiToSanFelipe GW Budget.GW Budget
CochitiToSanFelipe River Budget.ReachBudget
CochitiToSanFelipe River Budget.River SW Budget

IsletaToBernardo Canal Budget.Canal SW Budget
IsletaToBernardo GW Budget.GW Budget
IsletaToBernardo River Budget.River SW Budget

SanAcaciaToSanMarcial Canal Budget.Canal SW Budget
SanAcaciaToSanMarcial GW Budget.GW Budget
SanAcaciaToSanMarcial River Budget.ReachBudget
SanAcaciaToSanMarcial River Budget.River SW Budget

SanFelipeToCentral Canal Budget.Canal SW Budget
SanFelipeToCentral GW Budget.GW Budget
SanFelipeToCentral River Budget.River SW Budget

TotalAnnualBudget.BudgetSummary
TotalAnnualBudget.InMinusOut
TotalAnnualBudget.WettedSandEvap
  

Note: the corresponding "budget" groups (water balance groups) happen to be listed here in reverse order (with respect to the list to the left).

Here are some images related to one of their six parts (CochitiToSanFelipe):

So, going with only three levels (instead of four) -- and using six mass balance data objects in the URGWOM example -- is perhaps the best choice.  This does already represent a consolidation of the mass balance computation (from 17 data objects to 6).

*** NOTICE ALSO (unrelated) in the top-right Rpl expression slot (3rd bullet above, this image) that the last term is used TWICE.  Probably that's a mistake in URGWOM.  It's hard to tell.  That "budget" does balance throughout the whole time series, but that "doubled" term is itself all ZERO (throughout the whole series) -- so if it is an error for that term to be added twice, that wouldn't show up in the budget total.  The point is, we haven't planned on using any series more than once in a single collection.  Probably that's OK.

---