The Inflow node allows the user to define flow and/or constituent input to a Source model by adding point source inputs into a network. Inflows could include tributary inputs, inter-basin transfers, discharge from sewerage treatment plants, return flows from water users, and inflows from irrigation drains and groundwater inflows. Inflows and constituents are specified as a time series. An inflow node is not used to account for rain falling directly onto water storages (see the storage node description for this functionality).
Inflows, as specified by an inflow node, can contribute to supply of water orders. Inflows may also be ‘owned’ so may need to be taken into consideration when considering ownership and water accounting.
For explicit modelling of inflows and constituents please refer to the sections on flow generation and constituent generation.
The Inflow Node is implemented at the site-scale and represents a physical location on river network where point source inflows or constituents are added. The temporal scale is usually determined by the time-step of the input data. Common temporal scales are daily or monthly.
Introduced in Source Rivers.
Source version 4.5
The inflow node must be part of a node link network.
Inflow node is automatically installed with Source.
Structure and processes
Time series of flow and constituents can be input to a model using the inflow node. Ordering and ownership functionality can apply to the water added via inflow nodes.
The basic function of the Inflow node is to add water to a river network. Three techniques can be used to specify the inflow of water at an Inflow node:
- File - A time series of inflows can be loaded as a file which includes specification of a time stamp and the flow for each time stamp. For details on importing data files into Source, see the Source User Guide;
- Scenario - Flows can be imported from a scenario within the current project. This scenario must have been run for the data to be available; or
- Function - Flows can be specified as a function in the function editor
Inflows can also be forecast, see the section on forecasting for details.
Initialisation occurs before the order phase of the model commences. There are three steps to initialisation which are related to an inflow node. These steps occur in the following sequence:
- Where the inflow is defined using a time-series file or scenario the additional inflow for the current time-step is sourced;
- Where a forecast of inflows is made for use during the order phase. Inflows downstream of a storage are often considered by operators when determining releases required from the storage to meet orders. An operator can reduce the release from the storage on the basis that inflows downstream of the storage can be allocated to meet orders downstream of the inflow. Where there is a lag time between the storage and the point of inflow the operator will need to forecast what the inflows will be in the future. Source simulates this behaviour in the ordering phase. A number of forecasting models are available within Source and are detailed in Rules-Based Ordering - SRG.
- Where the inflow is defined through a function the additional inflow for the current time-step is determined.
The inflow node affects the order phase of a simulation if an inflow node is downstream of a storage and a forecasting model is used to make inflow predictions. In this case, the order passed up to the storage is reduced by the forecast inflow. Ordering is covered in more detail here.
If ownership is enabled, the forecast inflow is shared between owners based on a user defined ratio or function. Where an owner does not require all of the share of the forecasted inflow (as their share is greater than their orders at that point) then they can lend their excess to other owners. Ownership is covered in more detail in Ownership - SRG.
Reduce current order by the unallocated forecasted inflow:
- For systems which do not have storage in parallel with different travel times, the unallocated forecasted inflow is equal to the forecasted inflow;
- Otherwise, part or all of forecasted inflow may have been allocated. This is because orders may have been placed at previous time-steps with the same delivery time as orders being placed at the current time-step. In this case, the unallocated forecasted inflow is equal to the forecasted inflow minus inflow previously allocated.
Share forecasted inflow between owners based on ratio or function
- For each owner, subtract any prior allocation of forecasted inflows at this delivery time to determine the unallocated forecasted inflow;
- Reduce owner’s current order by the unallocated forecasted inflow;
- Allow borrowing of any remaining unallocated forecasted inflow. Refer to Borrow and Payback - SRG for details on borrowing systems.
All inflow nodes affect the flow phase. If forecast multiplier is enabled in inflow node, then Forecast Inflow = forecast volume (from inflow forecast model) * Forecast Multiplier.
During the flow phase the total flow downstream of the node is increased based on the inflow at that time-step. The components of the downstream flow which are allocated and unallocated are also updated if forecast inflows were allocated during the order phase.
Where enabled, the ownership of total flow and allocated and unallocated flow components are also updated during the order phase. Borrow and payback is also enabled during the flow phase which may be required when an owner’s inflow is different to that forecasted during the order phase.
When ownership is off:
- Determine the allocated and unallocated inflow at the inflow node:
- Determine the downstream total flow, allocated flow and unallocated as follows:
|Equation 3 |
When ownership is on:
- Assign inflows to each owner based on ratio or function;
- Determine the allocated and unallocated inflow for each owner as per step 1 for ownership off; and
- If an owner’s allocated inflow was greater during order phase, the shortfall can be met by borrowing where other owners now have unallocated inflow. If there is not sufficient surplus to make up the shortfall, then downstream users, including downstream storages, need to be notified of the shortfall. How these shortfalls and paybacks are shared is covered in the Borrow and Payback - SRG entry.
Constituents, either as time-series of loads or concentrations can be input from three sources:
- File - A time series of constituents can be loaded as a file which includes specification of a time stamp and the concentration or load for each time stamp. For details on importing data files into Source, see the Specifying data inputs chapter of the Source User Guide;
- Scenario - Constituents can be imported from a scenario within the current project. This scenario must have been run for the data to be available; or
- Function - Constituents can be specified by a function in the function manager.
The inflow of constituents must be accompanied by an inflow of water.
Where constituents are defined as a time series of concentrations the inflow of constituents at an inflow node is defined by the equation:
Lxl(t) is the inflow load of constituent x for time-step t;
Cx(t) is the concentration of constituent x in the inflow stream at time t; and
Ql(t) is the inflow at the node at time t.
The load of constituent from the inflow time series is added to the load of the same constituent at the node coming from other sources (such as the catchment upstream of that node). If the constituent inflow is the only node model applied at the node, then
Lx(t) is the load of constituent x at the node after addition of the inflow load; and
Lx,US(t) is the load of constituent x coming from the link(s) upstream of that node.
It is assumed that the time series of flows, constituent loads and constituent concentrations are average values for each time-step that are entered (not instantaneous values at the start or end of the time-step). For each time-step then, the constituent load inflow at the node is a product of the flow inflow at the node and the constituent concentration at the node.
It is assumed that variations in constituent concentration / load within one time-step are ignored and that the average value across the time-step can be used to represent the processes.
The forecasting functionality that applies to flows is not available for constituents.
Time series of flow and constituents data can be loaded into the input node. File formats are discussed in the Source User Guide.
At an inflow node, inflows are entered as a time-series for inflow volume per time-step of the model, eg. ML/day or GL/month.
For constituents input, the constituent that the inflow node model is to be configured for must be specified and the input type (load or concentration) selected.
Time series data must have no missing values and ideally be for the same time period as other inputs into the model. There must be at least an overlapping period with other model inputs.
Constituent loads can not be negative (zero or positive real values only). This applies to the inflow constituent load, as well as to the load of constituents coming into the node from upstream link(s).
Parameters are important for forecasting as explained in Rules-Based Ordering - SRG.
The output data is a time series of flow and or constituents.