Practice note: Naming nodes and links

This practice note is one of a set developed to provide consistency and transparency of river system models being used within the Murray-Darling Basin. The notes cover modelling practices, such as naming conventions for folder structures, to model methods, such as for flow routing and residual inflow estimation, and have been developed through a collaboration between the MDBA, Basin States and CSIRO.

Produced in collaboration with:

Practice note: Naming nodes and links

This practice note, Naming nodes and links, details the recommended conventions for naming nodes and links in Source river system models that underpin water resource plans; and provides examples of implementing the conventions.

Background

When building an eWater Source model, nodes and links are initially given default names, such as inflow 1, inflow 2, confluence 3, etc. These can be easily renamed and instructions on how to add and rename nodes and links can be found in the Source User Guide (Nodes and Links). Source does not support duplicate names for node and links.

General principles

• Nodes and links names should be clear and allow other modellers to easily understand the model layout.
• If a model contains multiple sub-systems, names should allow others to differentiate between the different sub-systems.

Conventions for naming model nodes and links

1. Valley identifiers (ValleyID) should be included in all node and link names. These should be unique for each model within the Murray-Darling Basin.
2. Where there is a node that represents a site with observed data (e.g. flow data, storage levels), the name should include the gauge name and number.
3. Names for water user node names should include:
   1. Valley Identifier
   2. Owner (if applicable)
   3. Reach identifier
   4. Description of the type of user (e.g. Town water supply, stock and domestic, Irrigation, Environment etc.)
   5. Description of location.
4. Supply Points should have the same name as the water user; a single water user with more than one Supply Point should be numbered in sequence from 1 to x.
   1. Where a model has ownership, the Supply Point name should include a description of the owner.
5. Environmental demands should include the Site Name/Description.
6. Residual inflows should include the downstream gauge name. Where there is more than one residual inflow between two gauge points, the inflows should be numbered in sequence from 1 to x.
7. Loss Nodes should be named after the calibration reach.
8. Splitters, Confluences, Minimum flow nodes, and Maximum order constraints should include a locality description.
9. Link Names should allow users to easily identify routing and non-routing links. Not all link names need to be altered from the default. The following links should use non- default names.
   1. Routing links
   2. Links upstream of confluences
   3. Links downstream of splitters
   4. Links downstream of storages
   5. Wetland links.

Examples

Table 1: Examples of implementing Node naming conventions (<> identifies elements that should be included. Italics indicates elements to be included, if applicable. Bold identifies fixed text. / indicates 'or'. The ordering of the components within the convention is not fixed) *ValleyIDs used in these tables are listed in Table 5

Table 2: Examples of implementing node naming conventions for gauged and ungauged Inflows (<> identifies elements that should be included. Italics indicates elements to be included, if applicable. Bold identifies fixed text. The ordering of the components within the convention is not fixed)

Table 3: Examples of implementing node naming conventions for Water Users (<> identifies elements that should be included. Italics indicates elements to be included, if applicable. Bold identifies fixed text. / indicates 'or'. The ordering of the components within the convention is not fixed)

Table 4: Examples of implementing naming conventions for Links (<> identifies elements that should be included. Italics indicates elements to be included, if applicable. Bold
identifies fixed text. The ordering of the components within the convention is not fixed)

Table 5: Valley identifiers (ValleyID) and other abbreviations used in these tables