Source Version 4.3 delivers new and improved functionality to help you solve some of the long-standing challenges in integrated water resource modelling. For example we've worked closely with MDBA and other stakeholders to deliver new environmental flow management functionality that allows for prioritisation across sites and works directly with entitlement systems. Urban models can now include looped flow systems via bidirectional flow using the new pipe junction node.
...
the new Source functionality allows environmental flow rules to be implemented at individual points within the system and can be configured to reflect the interconnected, spatially and temporally diverse nature of ecological system requirements and the overall impact of environmental water holdings on the system. This provides an explicitly defined, reliable environmental water management model in Source that can be easily related to the rest of the framework. The functionality can be used to fully realise a fit for purpose integrated modelling framework for water resources planning and management that enables the representation of planning, use and accounting of environmental water, and that can be used to carry out analysis of and therefore optimisation of alternative policy scenarios for environmental water allocation and use. The implementation of tools to configure generalised rules is a better option than individual users configuring large numbers of custom functions (which is another option), for ease of use, management and transparency.
The Environmental Flow Node is used to generate orders to meet in-stream environmental requirements at an individual asset. The desired flow patterns are defined by configuring one or more actions including start criteria, desired flow response and frequency, as well as criteria for determining if an action was successful and the condition of the asset targeted by the action.
The Environmental Flow Manager is used to prioritise environmental flow actions defined at Environmental Flow Nodes throughout the system. The EFM also handles management of environmental water accounts, and apportionment of water from an account or accounts to particular environmental events.
...
Shortfall Priority Management
Shortfall priorities allow users in Source to specify how shortfalls are allocated to different water requirements in rules-based ordering systems. It is configured at the scenario level and influences how water is supplied to supply points, minimum flow nodes and storages, and released by storages and splitters. Without a priority system enabled, Source will shortfall all demands proportionally within the model.
Scenario Options, Ordering Priorities
The minimum operating constraint at a storage only applies to water requirements of lower priority than the storage.
...
If the storage has more than one outlet path, the storage can be configured to attempt to meet higher priority outlet path requirements first in the event of a shortfall.
2) Operating Constraints and Targets
The Operating Constraints (formerly Operating levels) affect storage releases by trying to keep the storage level or volume within the specified range. The storage will not release water to satisfy lower priority priority downstream requirements if this results in the water level dropping below the Minimum Operating value. Likewise, water will be released up to the Safe Release Capacity (set at an outlet path) to prevent the storage rising above the Maximum Operating value, for example, if you wanted to leave airspace for flood mitigation. This functionality was previously only available for weirs, but is now available for storage nodes when Backwards Euler release method is enabled.
Operating Targets have now moved under the Ordering menu. An Operating Target refers to the level that the system will attempt to maintain in a downstream storage by ordering water from an upstream storage.
...
Weirs are now their own node. There is a new (optional) algorithm that may be used to model a weir as a triangular pyramid. The original algorithm only allwed allowed modelling the weir as a rectangular wedge. The new algorithm was developed from observations of hydrodynamic models, and more realistically models the wetted (surface) area as the weir fills up. This is useful for understanding the environmental impact of weirs. Weirs can't yet use the Backwards Euler method.
Catchments
Representing rain-fed crops in the catchment context
Rain-fed crops can now be modelled in place of a standard rainfall-runoff model as a functional unit within the catchment simulation. The agricultural runoff model represents the crop water use and agricultural runoff as part of the rainfall-runoff process. The daily crop water balance is based on the irrigator demand model and the method described in FAO56 (Allen et al, 1998). It models a daily crop water use, and generates runoff from rainfall excess from the functional units. The rainfall excess can be routed as quick flow and slow flow to the rivef river system. Crop use of water from small storages in catchments can be represented by on-farm storages (also known as check dams in some countries) within the agricultural runoff model. A number of the model parameters can be calibrated alongside other rainfall runoff models using the Source calibration wizard.
Distribution of Rainfall on a Link
...
eWater's software development team understands the importance of maintaining good practice for version control of our software code. We believe that these principles are of value to our Source users to help them manage their Source projects. We have implemented functionality to facilitate a Source project version control system. This will help you identify project changes over time such as model configuration, inputs and results.
Project Options, Project Summary Export
...
Combining models which run at different time-steps is now possible through the introduction of a data aggregation feature for scenario data sources, allowing for the results from a model run on a smaller timestep able to be used as in input into a model with a larger timestep eg. 6 minute to daily.
...
You may find some of your modelling results have changed between Source 4.1 and Source 4.3. The eWater development team maintains a detailed system to track when results vary between different version of Source. The details at the following link will help you work out why the results have changed, and any alterations you may need to make to your model configuration. Details of result changes: 4.3 Result Changes from 4.1