RiverWare 5.3 OLAM/Controller Work -- David's 2-16-2010 Review Notes
Edit 2-20-2010 ... (Hit Refresh)
| David / General Comments | Phil's Notes | |
| 1a. | [OLAM Execution Time Names] ... We say in a few places "as Inputs Change". Inputs don't change, dependent slot values change. So shouldn't we at least say "as Dependencies Change" or am I missing something? My advice for wording is as follows (consistent with expressions slots which has a similar concept) .... |
Tooltips are implemented on the ExecTime ComboBoxes in both the OpenObject and MOMs dialog. Also, on the MOMs method list items (but not in the OpenObject category list, because that's still in Qt3 -- not as easy to implement there). |
| 1b. | Not a new thing, but this may be a time to fix it: The names of the Object Level Accounting Method categories are horrible. The worst is on the reservoir: "Storage Account Slot Inflow". This categories applies to all accounts on the object including passthroughs. It should just be "Reservoir Slot Inflow". On the Reach there is "Reach PassThrough Slot Inflow" and "Pass Through Acct Gain Loss", yes with that capitalization and spacing. Can we fix all of these to be consistent??? These names are used in the OLAM RPL set too (for groups), so there could be some work getting them fixed correctly there too. | |
| David / Multi-Object Method Selector | Phil's Notes | |
| 2a. | If the dialog is at min width (default when I opened it), when you select an OLAM, it gives most of the width to the methods, and hides the categories. No Splitter either? This should improve with shorter names but could still be an issue. | IN PROGRESS. For some reason, Qt doesn't implement good "size hints" for lists and treeview widgets -- but we can. (The internal implementations don't take the list CONTENT into account!). Fortunately, the MOMS lists were ported to Qt4, so this makes sense to tackle. We have, in fact, implemented computed vertical size hints for list widgets. We just have to do that for the horizontal dimension; a bit more complicated. AND, maybe a SPLITTER would make sense here -- especially if we can't easily get this to work well automatically. Unless we can make splitters VISIBLE on Windows -- maybe we can -- I feel that relying on Splitters is a bad idea. |
| 2b. | "Initialize Target Account List Slots..." is not clear. Initialize implies I can do it before selecting the method, but that is not so. Maybe just say "Set Target Account..." | DONE |
| 2c. | I would think that if I set the execution time first, then apply the method, it should apply that too. | DONE. This would have been dangerous to implement if selecting a method in the method list doesn't also set the Execution Time Combo box to the method execution time shown for the objects already having that method selection. That functionality has been implemented, as well as the requested functionality of setting the method execution time when an OLAM method selection is applied. An exception to this is that the "never" method execution time is never overridden. |
| David / Initialize Account List Slot on Object | Phil's Notes | |
| 3b. | "Abort"? - Shouldn't this say "Cancel". We never use the term Abort. | DONE |
| 3c. | I have a few other wording and layout things which I printed and will give to phil. | Most changes were applied. |
| ... When choosing Accounts by Water Type (or Water Owner), it would be good to list not only the Objects which will be assigned values (in their Target Accounts slot), but also the Accounts that were assigned to that slot. | DONE. The names of relevant accounts are optionally shown in the Water Type and Water Type selection modes when exactly one or more than one account is being reported for one or more simulation objects. Those account names are shown only when a new checkbox is checked: [x] Show found accounts. SEE SCREENSHOTS. | |
| 3d. | You can create missing accounts? That seems a bit over-reaching of this dialog. How do you know which type of account to create on reservoirs? Maybe I wanted a passthrough instead of a storage acct. What if they should all be linked together? Then I would have to go back and create supplies by hand or delete them all and use the linked passthrough account creator. | We can remove this, but it may actually be very helpful in certain workflows. See my notes about this at the end of this webpage ("Proposed Enhancement"). |
| 3e. | Why not let them set it by Water Owner too? Water types would be used more commonly because that is what we use for SolveWaterRights, but I could see someone wanting to set it by water owner. | DONE |
| David / Target Account Slot | Phil's Notes | |
| 4a. | You can add multiple accounts to this list slots. Not sure what will happen, but maybe we can limit this to exactly 1 in the GUI. | IN PROGRESS. I'm adding a new _itemCountLimit (int) property to ListSlot (and ListSlotProxy) which will be enforced in the Open ListSlot dialog. |
| 4b. | You can add accounts that aren't even on that object. At the bare minimum, initialize GUS to that Object. | IN PROGRESS. I'm adding a new _limitToHostSimObj (bool) property to ListSlot (and ListSlotProxy) which will be enforced in the Open ListSlot dialog. |
| 4c. | You can add accounts that don't even have Slot Inflows (Diversion Account and Instream Flow). Maybe this is caught at runtime, I'll try it later. Can we prevent this in GUS? | I suggest not addressing this. The C++ templated architecture of ListSlot makes it difficult to add a property to the Account* instantiation of ListSlot. So, there's no good general way to convey to RiverWare code that a particular Account ListSlot instance should be limited to containing Accounts of particular types (or other specific criteria). |
| David / Functionality Issues | Notes | |
| 5a. | Are we going to limit the predefined basin-specific OLAMs to only go "After Simulation" as they do now? Some (probably most) of them won't work at any other time. I think Nancy spelled out what the dependencies are for each, but do we want to allow them to change execution time now? | |
| 5b. | Currently SolveWaterRights verification methods are setting Slot Inflows to zero at Beg of Run. This was a workaround that is better addressed by this work. Should we stop setting Slot Inflows to zero now and make users change models? | |
| 5c. | I get an error that "The current RPL application
(User-defined Object-level Accounting Methods) does not support the
concept of "controller's current timestep" when I execute the
following RPL OLAM at Beg of Run:
ThisObject ^ "AllocatableFlow.Slot Inflow" [] ==
ThisObject. "Inflow" [];
It does work if I switch this to execute at beg of timestep. It seems
we need to relax this restriction now. |
[Neil, 2-18-2010]: I consulted with Patrick and changed the concept of getCurrentDate for the OLAM RplApplication to be similar to the expression slot case, so that now the current date from Rpl's point of view can be set from the AcctControl beginningOfRun method as it iterates through all run timesteps and the Rpl expression will solve at the desired time. |
| 5d. | It looks like Simulation slots are not registering dependencies as noted in Nancy's work. I think this needs to change now. | |