Laserfiche WebLink
Outflow . Subject to reach losses between nodes, the calculated available flow (outflow) becomes <br />part of the inflow to the next downstream node. <br />Specific Aspects of Functionality <br />Reservoir Accounting . From inspection of the HYDROSS code and conversations with persons <br />familiar with its application, it was concluded that the model is not designed to accommodate <br />multiple accounts and/or priorities within a reservoir. There may be ways of specially coding the <br />input to the model to keep track of individual subaccounts, but this process is reported as being <br />difficult, and there would be problems and errors associated with being able to allocate evaporation <br />and seepage losses from the "parent" reservoir to all of the "children" reservoirs. There is also <br />concern about the logic of HYDROSS regarding the accounting of natural flows versus project flows <br />and rights. The code appears to be written with a primary objective of storing and releasing water <br />from project reservoirs. As stated above, unless a reservoir is assigned a decreed priority date and <br />the water is stored pursuant to a direct diversion (i.e., an off-stream facility), all stored water is <br />assumed to be project water. More detailed inspection of the source code would be required to <br />determine if this basic logic would need modification before HYDROSS would readily <br />accommodate the applications contemplated for the CRDSS. An attribute of the reservoir accounting <br />in HYDROSS is the apparent ability for a downstream ditch to designate more than one reservoir <br />from which to receive a delivery. <br />Exchanges . HYDROSS is not designed to handle exchanges. Users of the model have explored <br />ways of replicating water right exchanges by switching priorities at two diversion nodes. However, <br />it is not clear whether this process truly reflects the type of exchange that would need to be modeled <br />in the CRDSS, such as releasing water at one location in the network and diverting a like amount at <br />an upstream location, after checking the available flows in the intervening reach of the stream <br />(exchange potential). This may be a shortcoming in the suitability of HYDROSS for the CRDSS. <br />Return Flows . HYDROSS has the ability to calculate return flows which result both from diversions <br />and from reach losses (similar to a channel loss). The model allows for return flows to accrue to the <br />river in the same time-step (month) that a diversion occurs and can be assigned to accrue at multiple <br />nodes in the network. It is our observation that modeling return flows, in which a part of the returns <br />are available for diversion within the same time-step, may require an iterative procedure in order for <br />diversions pursuant to a water right to have the benefit of its own return flows. The amount of water <br />available for diversion for a given water right is dependent upon the minimum flow in the network <br />downstream of the point of diversion and the observed minimum flow should reflect the return flows <br />resulting from that current diversion. Lagged return flows can continue for up to 11 months and can <br />be coded either as a percentage of the diversion or in the form of a return flow table. <br />Other Issues <br />Additions and Modifications . The input format for HYDROSS is structured to easily allow the <br />addition of nodes (diversions, reservoirs, in-stream flow rights, etc.) in a relatively straightforward <br />manner. However, as discussed above, it would be difficult to modify the source code and/or <br />develop specific input for special conditions that will need to be addressed in the CRDSS, such as <br />multiple accounts/priorities/ownerships within a storage reservoir, water right exchanges, etc. <br />3 <br />A275 05.10.94 1.15-4 Fosha, Hyre <br />