Note: This is documentation for version 4.11 of Source. For a different version of Source, select the relevant space by using the Spaces menu in the toolbar above
Storage node
- teamcity (Deactivated)
- Teamcity
- Karina Redpath
Introduction
In regulated river systems, storages control the supply of water to consumptive and non-consumptive users, and may also provide flood mitigation, social and environmental services. In a river model, they represent places where water is stored along the river, such as dams, reservoirs, weirs and ponds. Storages operate by maintaining water mass balance.
Storage processing method
In Source, the storage node calculates water balance over the time step that is constrained by inflows, physical limits on discharges, downstream demands and gain and loss relationships.
There are two available methods in Source for processing flows and changes in storage volume, you can choose which method to use by navigating to Edit » Scenario Options, and selecting Storages.
Both methods assume that all storage variables are a piecewise linear function of the storage's volume.
The Piecewise-linear Integral method is the default method, and is the only method available in previous versions of Source (prior to 4.1). Changes in flows and storage volume are calculated by integrating continuously across the time-step. For more information, see Piecewise Linear approach to Reservoir Routing - SRG.
The Backward Euler method is a new, beta feature in Source 4.1. Changes in flows and storage volume are calculated by using a finite time-step approach. Selecting this method enables some functionality. You can configure storage operating levels, and also configure outlet path priorities.
NOTE: The Backward Euler Method is only available for storage nodes. Weir nodes only work with the Piecewise-linear Integral Method.
Configuring Storages
For all storages in Source, the following must be configured as a minimum in the node’s feature editor:
- Details of the storage such as its dimensions and capacity;
- Inflows to storages such as stream flow from upstream catchments, rainfall over the storage surface area, recharge from groundwater, and runoff from the catchment surrounding the storage;
- Outflows from the dam, which could be initiated either through controlled releases (to fulfill downstream demand or meet operating levels) or uncontrolled flows; and
- Losses that constitute evaporation from the storage surface area and seepage to groundwater.
Conversion between a storage node and a weir node is available through Tools >> Convert Storages and Weirs. The retained settings during conversion are:
- All the storage setting (geometry, rainfall, etc) will be kept
- Converting a "storage to weir" gives an upstream reach with default settings
- The downstream link and outlets will be retained
- Modelled variables will be retained
- Function and data sources will be retained
- Ownership and Constituent data will be retained
Note: Operations override data is lost
Storage details
The editor’s main window (Figure 1) allows you to specify storage details, which are outlined in Table 1. You are recommended to use the same units as those in Dimensions, but you can change them by clicking on their respective units buttons.
Figure 1. Storage node
Table 1. Storage node, details
| Parameter | Definition | Default |
|---|---|---|
| Hydropower generation | A drop-down menu allowing you to choose where to generate spill for hydropower generation. When a storage with an ungated spillway is close to FSL, and inflows would cause the storage to physically spill in the absence of release, the system can find it difficult to accurately determine if the generator could have been used to pass inflows, rather than the spillway. For example, if a storage is at the spill level of the ungated spillway at the start of the time-step, and there is inflow which could have been passed through the generator, the majority of the inflow will pass over the spillway. This situation arises when the correct configuration for a storage with only ungated spillways is used, ie, Don't generate from spill is chosen. Actual generation in such situations would depend on the operating rules for the reservoir, and pattern of inflow though the day. It is not possible to define a single generically applicable solution for this. Similarly, if the storage is below spill level, and inflow is such that the storage would spill without releases, and downstream demand = inflow (and therefore the storage wouldn't physically spill), Source sets a minimum release which is interpreted as physical spill. Choosing Generate using spill will generate from all spill limited ONLY by hydropower valve capacity Choosing Generate using spill; upto downstream orders will generate spill limited by downstream orders and hydropower valve capacity. | Don't generate from spill |
| Full Supply | The level or volume for which uncontrolled flow commences over an un-gated spillway. | Equal to the level of the spillway. |
| Initial Conditions | The initial water level/volume in the storage at the start. This level must be above or equal to the minimum storage water level defined in the storage dimensions relationship. | There is no default value, but it can be a non-integer, with the minimum being the lowest storage dimension level. |
| Dead Storage Capacity | The level or volume below which water cannot be released from the storage. This is different for rules-based and netLP ordering. Refer to the note below. | 0 |
| Node elevation | The node's height above sea level (this value can be negative to represent an elevation below sea level) | 0 |
Operating constraints and targets
Operating Constraints
Operating constraints are only available if either the Backward Euler method is chosen as the storage processing method, or the storage has been configured as a Weir. Operating constraints are not available if the network has been setup for netLP ordering.
The operating constraints affect storage releases, keeping the storage level or volume within the specified operating range. You may select whether the contraints are specified by volume or level using radio buttons provided, and then the unspecified property will be calculated using storage dimensions. The storage will not release water to satisfy downstream requirements if this results in the water level or volume dropping below the Minimum Operating constraint. Likewise, water will be released to prevent the storage rising above the Maximum Operating constraint (Figure 2).
Releases down an outlet path made in an attempt to meet the maximum operating constraint are limited to the safe release capacity for that outlet path. This is configured by selecting the outlet path from the tree menu, enabling Use Safe Release Capacity and entering a flow rate for the Safe Release Capacity (Figure 9, see Outlets). Note that if you do not provide a safe release capacity for an outlet path, then no releases will be made for the purpose of meeting the maximum operating level but releases to meet normal demand requirements should still happen. The safe release capacity should be less than maximum outlet capacity. The safe release capacity can be set bigger than the maximum outlet capacity, but releases through this outlet will be constrained to the maximum outlet capacity.
Figure 2. Storage Node, Operating Constraints
Operating Targets
Operating Target refers to the level or volume that the system will attempt to maintain in a downstream storage by ordering water from an upstream storage. You may select whether the targets are specified by volume or level using radio buttons provided, and then the unspecified property will be calculated using storage dimensions (Figure 3).
The Maximum Unregulated Operating Target captures surplus water during an off-allocation event. It specifies a target level or volume in the storage that is used by the off-allocation system in determining how much water may be allocated to the storage during the off-allocation event.
Figure 3. Storage node, Operating Target
Storage dimensions
Storage dimensions can be configured to be either static or vary over time (see Time-varying storage dimensions). You can use time-varying storage dimensions to model the gradual decrease in storage capacity caused by sedimentation, or to model the abrupt increase in storage capacity from implementing a new dam.
Static storage dimensions
To configure dimensions that remain constant for the duration of the model run, select Dimensions » Static Storage Dimension (Figure 4) and then specify the dimensions using level, volume and surface area. Dimensions can be entered manually as a piecewise linear relationship or imported as a comma-separated file (format shown in Table 1). There is no need to specify a start date, this is used for configuring time-varying storage dimensions. You can also export the relationship for use in another scenario. The graph displays a relationship between Level vs Volume or Level vs Surface Area, which can be changed using the drop down menu.
Figure 4. Storage node, Dimensions
Table 2. Storage node, Dimensions (data file format)
| Row | Column (comma-separated) | ||
|---|---|---|---|
| 1 | 2 | 3 | |
| 1 | Level (m) | Volume (ML) | Surface Area (ha) |
| 2 | -10 | 0 | 0 |
| 3 | 0 | 100 | 500 |
| 4 | level | volume | surface area |
Example Storage Dimensions File
Level,Volume,SurfaceArea473,0,0475,100,0.1478,4600,2.9479,8100,2.9
Time-varying storage dimensions
Storages can be configured to increase and/or decrease in storage capacity over time, these changes can be gradual or happen in a single time step.
To vary storage dimensions over time, at least two storage dimensions need to be configured, each with a different start date, so that Source can interpolate between them. To add a second storage dimension, right click on Dimensions and select Add Storage Dimension from the contextual menu.
For each storage dimension, configure the level, volume and surface area relationship as explained for Static Storage Dimensions.
Start Dates
For each storage dimension, set the Start Date to the date from which the dimensions apply. The start date is also the storage dimension's name. If you have a static storage dimension configured and you add another storage dimension, the static storage name will also change to its start date (default is 01/01/1880).
If the start dates for all storage dimensions are after the start date of the run, then the storage dimension with the earliest start date is used at the beginning of the run.
Interpolation
You can configure how Source interpolates between storage dimensions by selecting Dimensions and then toggling on or off Interpolate Between Storage Dimensions. When toggled off, the second storage dimension will take effect from configured start date. When toggled on, the storage dimensions are linearly interpolated between the first start date and the second start date, and so on.
The period of the model run does not effect the interpolation.
Changing between storage dimensions
- If the storage volume decreases, then the level is set as constant between the two time steps. This is because decreases are assumed to be caused by sedimentation, which results in a loss of water volume (ie. storage volume), because some of the 'water' was actually sediment. This loss can be recorded with the Loss to Storage Dimension Change parameter.
- If the storage volume increases, then the volume is set as constant between the two time steps, this may result in a decrease in storage level. This is because increases are assumed to be caused by construction work to increase storage capacity.
The following is an illustrative example to demonstrate the effects of:
- Increasing and decreasing storage dimensions,
- Enabling Interpolation Between Storage Dimensions, and
- Model run commencing before the earliest storage dimension start date.
A model was configured with constant flow, and a storage with three storage dimensions (Table 3).
Table 3. Example of time-varying storage dimensions
Storage Dimension Start Date | Level (m) | Volume (ML) | Surface Area (km2) |
|---|---|---|---|
| 05/04/2016 | 0 | 0 | 0 |
| 100 | 200000 | 1000 | |
| 15/04/2016 | 0 | 0 | 0 |
| 100 | 100000 | 500 | |
| 25/04/2016 | 0 | 0 | 0 |
| 100 | 200000 | 1000 |
The second storage dimension decreases in storage capacity relative to the first. The third storage dimension increases the storage capacity relative to the second (Table 3).
The model was run from the 01/04/2016 to 01/05/2016. The beginning of the run (01/04) is before the first storage dimension starts (05/04), so the initial storage dimensions are considered to be those configured for the 05/04, but interpolation does not start until the 05/04.
The results of this configuration on Storage Volume, Level and Loss to Storage Dimension Change are shown in Figure 5. Interpolation was toggled on (solid lines) or off (dashed lines).
Figure 5. Example of time-varying storage dimensions.
Constituents
These inputs are required for water quality constituents, and can be specified by selecting Constituents. Ensure that constituents and constituent sources have been defined prior to configuration (using Edit » Constituents). Refer to Constituents - Storage node.
Gauged Level
The Apply Unaccounted Difference to Storage level calculation check box allows you to enable modelled values to be overridden by observed values. The storage level forces the parameter to equal the observed value. You may want to use this for calibration or for storage inflow derivation using the Unaccounted Difference recorder. You can specify the source data as a single value, link it to a time series (using Data Sources) or a function (using the Function Editor), as shown in Figure 6. You can also specify the gauged value as a level or volume, and the unspecified property will be calculated using storage dimensions. The storage node icon changes to indicate that modelled data is being overridden (Figure 7).
Figure 6. Storage node, Gauged level
Figure 7. Storage node icon, observed data replaces modelled data
Gauged Releases
This menu item allows you to overwrite modelled storage releases with observed releases, for example for the purposes of flow routing calibration in the reach downstream of the storage. First, click on the disclosure triangle next to Gauged Releases to view a list of available outlet paths, then right click on an outlet path to enable. Enter the observed data either as a single value, a time series (using Data Sources) or a function (using the Function Editor), as shown in Figure 8. The storage node icon changes to indicate that modelled data is being overridden (Figure 6).
Figure 8. Storage node, Gauged releases
Outlets
Outlets (Figure 8) define how water is released from the storage and must be added to allow for spills. In Source, you must specify the following:
- Outlet path – the path (out of the storage node) taken by the outlet. To choose an outlet path, click on the disclosure triangle to open a list of links connected to the node. You can choose the link that is associated with an outlet by right-clicking and choosing the outlet type;
- Outlet types – right-click on Outlets and choose the outlet type from the contextual menu.You can add more than one outlet type per storage. These are shown in Table 4; and
- Storage Outlet Capacity - For each outlet you can enter a relationship between storage level and discharge as a piecewise linear relationship (format shown in Table 5.)
Select an outlet path from the tree menu to view the Total Outlet Capacity table, which is a piecewise linear relationship accounting for the combination of all the release types for that outlet path (eg. if you have a spillway and a valve, Figure X). If Backward Euler is chosen as the storage processing method, this dialog is also where the Safe Release Capacity is configured (Figure 9), see Operating Constraints. To see the Total Outlet Capacity table for all outlets in the storage select Outlets.
Table 4. Storage Outlet Types
| Outlet Type | Description | Piecewise linear function required |
|---|---|---|
| Culvert | A conduit is used to enclose a flowing body of water. It may be used to allow water to pass underneath a road, railway or embankment. | Level vs discharge |
| Gated Spillway | Controls releases by the operation of gates. This allows for arange of discharges rates for each water level, depending on how wide the gates are opened. | Level vs minimum and maximum discharge |
| Hydropower Valve | The power generated from a hydroelectric system. | Level vs maximum discharge |
| Pump | Used to extract water from the storage (rather than allow discharge). This may be used where the location of the demand is at a higher elevation compared with the storage, or to extract water from the dead storage and which is below other release structures | Level vs maximum water pumped |
| Un-gated Spillway | A structure that controls the spill of water from a storage. It is designed to spill water once the storage is full and ensures that any spills are controlled. This prevents the storage from failing. Un-gated spillway rating tables are used to populate the Discharge table. The full storage level should have a zero discharge and the discharge depth needs to be calculated as the height above the full storage level. | Level vs discharge |
| Valve | Used to release water via a pipe. Valves normally release environmental flows from storages. The valve rating table is used to control the volume of water released via this method. | Level vs maximum discharge |
Table 5. Storage node, Seepage (data file format)
| Row | Column (comma-separated) | |
|---|---|---|
| 1 | 2 | |
| 1 | Level (m) | Seepage (mm/d) |
| 2 | 0 | 0 |
| 3 | level | seepage |
Figure 9. Storage node, Outlets
Outlet Path Priorities
Priorities are only available if the Backward Euler method is chosen as the storage processing method. You can configure the priority given for releasing water from the storage's outlet paths by toggling on Enable Prioritisation of Outlet Paths and then entering priorities for each outlet path into the table (Figure 10). These priorities only take effect when there is insufficient storage capacity to meet all orders. In this case, all the demands at priority 1 are met first, then priority 2 demands, and so on.
Figure 10 Storage node, outlet path priorities
Rainfall
Rain falling directly over the storage reservoir can be input as a time series, using the Function Editor (such as adding a daily or monthly pattern), or linking to the output of another scenario, as shown in Figure 11. It is assumed to occur only on the surface area. Daily rainfall data near the storage is required and can be obtained from managing agencies, SILO or the Bureau of Meteorology.
Figure 11. Storage node, Rainfall
Evaporation
Evaporation directly from the storage surface can be input as a single value, as a time series or a function (Figure 12).
Figure 12. Storage node, Evaporation
Seepage
Water can infiltrate into the ground where the soil is not fully saturated. Where groundwater intercepts the surface, water can seep from groundwater into the storage, where infiltration can occur wherever there is a ground/water interface. Seepage (Figure 13) is specified using a piecewise linear relationship between storage level and seepage velocity. Note that you can specify positive values to represent water seeping from the storage and entering groundwater. The data file format for seepage is shown in Table 5.
Figure 13. Storage node, Seepage
Ordering at storages
The following two options are mutually exclusive. If one is enabled, the other is greyed out (Figure 13).
If Pass Orders Straight Through Storage is enabled (Figure 14), then the storage level for forecasting seepage and evaporation losses is:
- For weirs min (current level, Maximum Operating Level); and
- For storages min (current level, Full Supply Level).
Otherwise min (current level, Operating Target).
If Do Not Order From Upstream Storages is enabled, then the storage acts as if it has no storage nodes upstream of it for the purposes of ordering. This is useful when a storage has the capacity to fulfill all downstream requirements, and will not need to order water from upstream storages.
Performance Improvement
Enabling Do Not Order From Upstream Storages on a storage limits the maximum travel time for any node downstream of it to that storage; storages upstream of it are not considered during maximum travel time calculations. When this option is enabled, the application will do less future prediction of water requirements, improving performance of the ordering phase. This can significantly improve run times in models that have ordering and long travel times.
Figure 14. Storage Node, Ordering
Ownership in storages
In ownership, observed values may not be available for every time-step. Additionally, observed values cannot include negative numbers, as ownership of storages can potentially result in negative shares when you support borrow and payback. Refer to Figure 15 for details and Ownership for more information.
Figure 15. Storage node (Ownership)
