eWater is pleased to announce the latest Production Release of Source version 5.4.

Key enhancements in version 5.4 include improvements to the Order Crawler, introduced in Source 5.0 for analysing orders, improvements to the Tabular Editor to support river operations and additional recorders to better understand water ordering with functions. Improvements to the Urban Developer plugin include better end-use customisation and new graphs to explore appliance water use.

Improvements to Source

A new recorder for analysing orders

We have built on the Order Crawler first released in Source 5.0. The new recorder can better analyse the progression of rules-based orders through complex planning models, in particular those with multiple flow paths and travel times. It shows all the nodes and links in a network and what their orders and requirements are on a particular date. This was designed as a debugging/analysis tool for the rules-based ordering system. Available under: Miscellaneous \ Ordering \ Order Crawler. The Order Crawler is a fully interactive zoomable schematic that can show:

Min Constraints (All, Min Travel time, Max Travel Time, Min & Max)
Max Constraints (All, Min Travel time, Max Travel Time, Min & Max)
Orders \ Requirements (All, Min Travel time, Max Travel Time, Min & Max)
Downstream Flow
Travel Time (Min and Max)

Note that for large networks, it does record a lot of data and is primarily for problem-solving and is not intended to always be turned on.

Order recorders

Additional recorders were requested to better understand the water that has been ordered when using functions. We have added recorders at each node with the following names under rules-based-ordering:

Orders > Arriving Current Timestep (expected)

Orders > Minimum Travel Time

Orders > Maximum Travel Time

Note Arriving Current Timestep (expected) is equivalent to the original Orders recorder.

River Operations Tabular Editor Improvements

The operations tabular editor now shows what cells can be edited, and can include comments on cells. Comments can be added to cells whether values are overridden or not:

You can also view all overrides and cells with comments using View Overrides:

You can also Clear Historical Overrides through this view.

Weirs and Constituents

The previous logic for running Constituent Instream Processing for Weirs was based on the logic for Storages.

The Instream Processing model was given the entire body of water associated with the feature.
The processing model would run once per time step for each constituent.
The Instream Processing model did not handle the upstream link component of the weir.

This was different from how these models behave for Storage Routing Links. Which is:

given access only to a single division, and
run once for each division and constituent in a Link.

The previous logic wouldn't work when the model included hard limits e.g. in this model, the average concentration is not meant to exceed 9mg/L. When the Model runs for the entire Weir, we can see this is true on average:

But when we look per division, we can see that some divisions drop to 0 while others can reach double the cap 18.

Changing the logic for weirs to be consistent with storage routing resolves this issue since the cap is applied in each division rather than across the entire link.

Constituent Instream Processing for Weirs is restricted to Marker routing, i.e. it is not implemented for Lumped routing. (If Lumped routing is being used storages would make a more sensible model for the infrastructure than weirs.)

Sub Source plugin improvements

Previously mappings between main and the sub-models called from the main model were tied to a single run configuration. If you make a new run configuration then the mapping has to be redone. Sub Source mappings have now been moved into a manager so that the same mapping can be used by multiple run configurations. Available under Tools » Sub-model Manning Manager.

We have also improved how Sub Source works with single projects. For single projects, the plugin will now:

get meta data from the loaded project rather than starting the service when doing configuration, and
Run the current project without needing to manually save before the run

Documentation is available here: SubSource Plugin

Urban Developer

eWater’s Urban Developer Tool gives water managers the ability to undertake a detailed analysis of household demand and water supply options, taking into account the range of dwelling types, water end uses, the water efficiency of different appliances and fittings, and lot size water harvesting/re-use options. As a plugin to Source, Urban Developer allows for a sophisticated small scale assessment of urban water demands to be undertaken within a larger scale Source planning model.

Custom end-uses

Custom end-uses can now be defined under Edit \ Urban Developer Options. Right click Custom End Uses to add your own.

Appliance configuration

Appliance configurations now have graphs to provide more insight into water use, an example for showers is shown below

Summary of minor changes

You can now specify the path that Source will use for storing temporary data and applications settings. Available under Edit \ Application Settings...
Marker routing can now use constituent processing models at Weirs and in Storage Routing links.
Feature table (and other tables) now includes units when exported.
Environmental Flow Nodes have a new recorder for consecutive successful time steps.
Functions or modelled variables that are used and don't have a Time of Evaluation (ToE) set will trigger a new assurance rule with an error by default.
The maximum node limit of 2,000 nodes has been removed.
Off Allocation with Non-Debit accounts now use entitlement rather than balance for the Without Debit Diversions (WDD) component.
Without Debit accounting changes (specific to NSW systems).
Urban Developer - when linking a Source scenario to Urban Developer Scenarios, you can now use the Urban Water User Parameteriser for all existing end-use types.
Other minor bug fixes.

Community Plugin Changes

We have moved to .net 4.8.0 which requires Visual Studio 2019. We are planning on moving to .NET 5. The transition to .NET 5.0 won't be a quick process as some components we currently use will no longer be supported, however it does provide a potential pathway to running natively on Linux. Source can currently be run on Linux under Wine, but only natively on Windows.

Results and Configuration Changes

Some results have changed between Source 5.0 and Source 5.4. Changes include how marker constituent processing works in Weirs. Details are available here: 5.4 Results and Configuration Changes from 5.0

Browser not supported