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.
...
| Table of Contents | ||
|---|---|---|
|
Environmental Flows
Environmental flow requirements describe the quantity, timing, and quality of water flows required to sustain freshwater and estuarine ecosystems and the human livelihoods and well-being that depend on those ecosystems.
...
Environmental Flows User Guide and /wiki/spaces/SD43/pages/53543940
Pipe Junction Node
Source has a new node type called a pipe junction. A pair of pipe junctions can pass flows and orders to each other no matter where they are in the system. One application of this is the ability to model bidirectional flows between storages in rules based ordering.
...
They are also available in NetLp.
Run Time Performance
eWater maintains a suite of models within our test matrix to monitor performance metrics such as run, load and save times. This release delivers significant improvement in model run times, with some models running more than six times faster than when we began our focus on performance. Our large test models have greatly improved, with the River Murray model running 43% faster.
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.
Storages
The new /wiki/spaces/SD41/pages/25822294 has enabled us to implement more water management options within storages such as:
1) Outlet Path Priorities
If the storage has more than one outlet path, the storage can be configured 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 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
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 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.
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 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
You can now choose whether rainfall-runoff is distributed to the upstream or downstream end of the receiving link. Upstream distribution means that the time delay for routed flow (from an upstream catchment) is also applied to the sub-catchment's rainfall-runoff. Because the application of baseflow is then through the routing link rather than the runoff component of the rainfall-runoff model, this can affect rainfall-runoff model parameters and constituent generation models. New models will have downstream distribution set as default.
Geographic editor
Easily delete sections of a large network in the improved geographic editor. To multi-select and delete nodes, links and catchments, use Ctrl+Click or lasso select (new) and simply press delete.
Model Management
Model Version Control
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
...
If you would like more information or help setting up a version control system to use with your Source projects, please contact us.
Recorder Sets
You can now easily switch between groups of recorders by using recorder sets. Similar to scenario input sets, they can be created from existing recorder configurations, specified manually using the text editor, or from a file. To access configuration, select Edit >> Recorder Sets.
...
Multiple recorder sets can be enabled and recorded in a model run.
Data Aggregator
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.
Time Series for initial values
You can now specify initial values for Storages and Resource Assessment using a time series or function rather than having to edit all initial values when you change a run period.
Functions and Modelled variables can now be evaluated at the start of run instead of specifying initial values. Previously, at the start of a run, all the modelled variables were set to the initial value specified (0 by default). If the function using the modelled variable has a time of evaluation before that of the modelled variable, the modelled variable will not have obtained it's first value in the first time step, and the set initial value will be used.
SubSource Community Plugin
The SubSource plugin runs a second Source model at different points during the main model run. For example in the figure below the main model (blue): steps through the simulation period, using Sub model (yellow) to calculate water losses to the end of the water year to improve allocation calculations.
...
At each call from the main model, the sub model (yellow) simulates the Dry (worst case) scenario until the end of the water year to estimate harvestable inflows and losses for the main model.
Other Features
There have been a large number of other changes, details are available in the beta release notes, including:
...
We are now moving to a new software release cycle, with a production release of Source every 6 months. Our priorities for the next release will be to make sure the Source User Guide and Scientific Reference Guide are up to date, and a focus on reporting and charting functionality. If you have ideas for additional Source functionality to help your work, we're always open to collaborative projects to help develop customised functionality and implement it in your modelling work, so stay in touch.
Results and Configuration Changes
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