Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

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

Version 5 includes the release of Urban Developer and MUSICX functionality as plugins to Source. This is a significant step forward for Urban water analysis. By using these three tools together, water managers have the ability to assess and plan for truly  integrated water management solutions, that consider water quality and quantity, at a range of scales.   

MUSIC and Urban Developer were originally designed to complement each other, to draw together information on urban water quantity (Urban Developer) and water quality (MUSIC) to develop integrated water management solutions in urban areas. These models can now be integrated with eWater Source catchment and river system models. This allows users to analyse interactions between different components of the water cycle and jointly evaluate demand and water supply options.  This provides water managers the tools to understand the best balance of traditional centralised bulk water supply, demand management and alternative water supplies, including the use and recycling of stormwater, wastewater and groundwater.

Question - should we acknowledge the investment by Melbourne Water and us?
GD:I think it would be good to acknowledge them.  Yep.  But need to run it past them first.  Also need to acknowledge the broader urban beta testers etc?

Source 5.0 also contains a broad range of other upgrades and enhancements to the platform, including changes to support river operations management, a new ordering system analysis tool, a range of performance improvements, and greater control over the interaction between planned constraints on supply, planned orders, and water deliveries.

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.

With Urban Developer you can assess the full range of indoor and outdoor water uses for four types of dwelling -  detached house, detached house with a rainwater tank, semi-attached house and apartments. It generates a database of average water demand for every combination of household type, occupancy and end-use, for the given climate. Urban Developer takes into account the full range of water efficiency End-uses include showers, hand taps, toilets, washing machines, dishwashers, pools and outdoor use.

image2019-2-1_9-19-58.png

Urban Developer helps water managers understand factors such as:

  • the potential demand savings from different water-efficiency measures
  • the impact on demand when dwelling types change, for example, detached housing is replaced by apartments
  • the volume of non-potable household demand that could be replaced by alternative water supplies
  • the effect of small scale potable water substitution on the bulk water supply/treatment system including water storage and bulk water supply distribution/sewage networks

MUSICX

MUSIC - Model for Urban Stormwater Improvement Conceptualisation) is Australia’s leading tool for water sensitive urban design. MUSIC is used by urban developers, planners, engineers, local government and development approval agencies to manage the impact of urban development and other land-use changes on receiving waters.

eWater has recently released MUSICX, the most significant upgrade to the tool in a decade. MUSICX will soon be available as a plugin to Source. 

With MUSIC you can:

  • simulate urban stormwater systems from the individual lot to suburb scale
  • estimate the potential for stormwater harvesting and reuse and understand the effects on downstream flows and water quality
  • model pollutants, including suspended solids, total phosphorus and total nitrogen
  • compare the water-quantity, quality and cost/benefit objectives of different treatment options, such as swales, bio-retention system, rainwater tanks, wetlands etc
  • design urban development proposals that meet WSUD standards.

Improvements to Source

Source 5.0 also includes a range of upgrades and enhancements, as described below.

River Operations 

We have been working with the MDBA to operationalise Source in operations mode. A focus has been enhancements to the Operations Tabular Editor. The editor is now more stable, easier to use, allows you to seamlessly add and remove nodes and is independent of the recorder selection.

NB: Geoff D to add a new picture

A new recorder for analysing orders

We have developed a new recorder to better analyse progression of 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 ordering system.  Available under: Miscellaneous \ Ordering \ Order Crawler. The Order Crawler is a fully interactive zoomable schematic that shows:

  • order data for all nodes and links (water users show their requirements)
  • the entire network with node locations in the same location as the network
  • the minimum order time values (same value as order recorder) e.g. if order travel time is 3 (minimum) to 5 (maximum) days the orders for 3 days out will be shown.

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. We will do more improvements to this tool for the next production release.

A new Water User and Constraint Phase

The function system has been augmented to provide more information around when constraints happen, to make information available earlier and finer control over function execution during the ordering process.     Just put a link for the below to a confluence page ...

Phase logic has changed from:

10. Ordering phase:
  1. Evaluate functions and modelled variables - where Time of Evaluation equals Order Phase and where the function is not used at a network element.
  2. Process Water Users: 
    1. Water User order calculations can be run in Parallel at this point in the ordering phase with the option enabled: "Process Water User Orders in Parallel": Scenario Options \ Performance
    2. For each Water User:
      1. Evaluate functions and modelled variables - where Time of Evaluation equals Order Phase, and where the function is used at this Water User.
      2. Calculate and distribute the demands of each Water user.
  3. Constraint Phase:
    1. For each Network Element:
      1. Calculate minimum and maximum constraints at each element and pass the constraints downstream.
  4. Ordering Phase:
    1. For each Network Element:
      1. Evaluate functions and modelled variables - where Time of Evaluation equals Order Phase, and where the function is used at this network element.
      2. Calculate regulated orders and pass upstream.
      3. Calculate off allocation orders and pass upstream.

To:

10. Water User and Constraint Phase

  1. Evaluate functions and modelled variables - where Time of Evaluation equals Water User & Constraint Phase and where the function is not used at a network element.
  2. Process Water Users: 
    1. Water User order calculations can be run in Parallel at this point in the ordering phase with the option enabled: "Process Water User Orders in Parallel": Scenario Options \ Performance
    2. For each Water User:
      1. Evaluate functions and modelled variables - where Time of Evaluation equals Water User and Constraints Phase, and where the function is used at this Water User.
      2. Calculate and distribute the demands of each Water user.
  3. Constraint Phase:
    1. For each Network Element:
      1. Evaluate functions and modelled variables - where Time of Evaluation equals Order Phase, and where the function is used at this network element.
      2. Calculate minimum and maximum constraints at each element and pass the constraints downstream.

11. Ordering phase:

  1. Evaluate functions and modelled variables - where Time of Evaluation equals Order Phase and where the function is not used at a network element or is used at a Water User.
  2. Ordering Phase:
    1. For each Network Element:
      1. Evaluate functions and modelled variables - where Time of Evaluation equals Order Phase, and where the function is used at this network element.
      2. Calculate regulated orders and pass upstream.
      3. Calculate off allocation orders and pass upstream.

The important thing to note is that the timing has changed.

Example: A function assigned to a Water User, that says it evaluates in the Ordering Phase, will now happen later than it previously did. To evaluate it at the same time as it did in v4.11, the time of evaluation needs to be moved to the Water User & Constraint Phase. To minimise the effect in splitting this phase in two, we've written some migration code.

The logic is:

  • IF a function or modelled variable has a time of evaluation of 'Ordering Phase' (in v4.10.1)
  • AND it is used on a model that is either:
    • a Non-Network Element (e.g. Resource Assessment, Env Flow Manager)
    • a Water User
  • THEN move its time of evaluation to 'Water User & Constraint Phase'

also

  • IF a function or modelled variable has a time of evaluation of 'Ordering Phase' (in v4.10.1)
  • AND it is not used anywhere
  • AND it has Force Evaluate set to On
  • THEN move its time of evaluation to 'Water User & Constraint Phase'

otherwise, we leave it as 'Ordering Phase'

Limitations

We know our migration codes is not perfect:

  • We don't cater for Functions activated via input sets. 
  • Functions not used on a model, but only used by other Functions will not be moved

Recommended steps

We recommend you review any functions that are evaluated in the ordering phase and ensure they are configured correctly using: Edit \ Feature Table.. \ Functions.

Results Streaming

Results can now be streamed to files on disk rather than stored in memory. This is to prevent memory issues with large runs.  Results streaming is off by default, however, it can be turned on in Project Options:

The format used (called Source Time Series Database .sdb) is now also available as a general time series format.  There is also a new command line utility for interacting with the format: Source.DataUtility.exe run with --help to see the instructions for interacting with the utility.

Performance improvements

We have made changes to significantly improve performance for editing and saving in some large models, for one project this reduced the time to save from 12 minutes to 45 seconds. 

We have also improved the performance of the command line so that less memory (RAM) is now used during a run.  Run times have been significantly reduced in the command line.

The command line now has additional options for results saving:

--resultsOutputMode

There are three modes available:

  1. NoOutput - Does not save results anywhere, hence does not fetch results either. Can be used where the result data files are ignored. E.g. in tests, or where a plugin gives a different pathway to results. This improves performance when using automatic exporting tools such as Scenario Options: Simulation results or Simulation Log which automatically exports results after each run to a specific location. 
  2. ClientNamedFormat - Results fetched to client, saved to output file from there, in a format based on output file extension. The data is transferred back to the client and saved (current behaviour).
  3. ServerNamedFormat - Results saved to output file directly from server, in a format based on output file extension. Does not fetch results to client. This "server side" save is more efficient. Default for InProcess mode, since "server side" is local here. Can be used in Client mode, assuming the end user has access to the path provided to the server e.g. a network drive.

Summary of minor changes

  • Data Sources can now find data based on the column name rather than the index. Being able to match by name is important when using Reload on Run. Match data items by Name is now the default option.
    It will validate and fail to run if you are matching based on name and reload a file with duplicate names.
  • Custom charts now include a search bar and more menu items under right-click. Customs charts are also no longer saved by default. All automatically generated charts are created under Temporary and only saved when moved into Saved. Users can also create folders and subfolders for organising custom charts.
  • Constituent Trend and % removal model. Links and Storages decay models have been extended to include a decay to a background concentration rather than to 0 and a % removal that can occur after the decay.
  • We have made calendar Date Ranges behave closer to expectation. This will change results for a number of users, so we have implemented a Scenario Option to turn on the new Date Ranges algorithm. Existing projects won't by default use the new method, and will have to be manually swapped over. This gives users a chance to test the new implementation before it becomes the only option.

  • We have introduced the concept of Locking to the Function Modelled Variables. Selected variables can now be locked, making it less likely for modelled variables to be inadvertently reassigned to different recorders. 

  • Ordering for the Irrigator demand model now includes an option to make the Flow phase and Order phase identical.  This was introduced for Pipe Junctions, and means today's weather (rain, evaporation) will no longer cause irrigator demands to change between order phase and flow phase within a timestep.

  • The GUI for the Resource Allocation Table in Resource Assessment has been made easier to use - you can now freeze columns and drag columns to reorder the columns in the Allocation Table within Resource Assessment.

  • Annual Accounting recorder changes. Some annual accounting recorders at RAS system level were giving incorrect values. The recorded values of "Total account spill reduction", "Total usage water year" and "Total Account Adjustments" at RAS system level values will change.
  • Ownership adjustment for storages and weirs - End of day volumes in Storages and Weirs can now be adjusted.
  • We have made changes to the version numbering system to help users understand when they need a new version of Source to open projects. Details are available at: 4.13 - Beta Release (June 2020)

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 4.11 and Source 5.0. Result changes are mostly around the Pipe Junction node, Weir infiltration, and Constituents in wetlands. Details are available here: 5.0 Result Changes from 4.11



  • No labels