Title - IQQM to Source Converter

Overview

Description and rationale

Provide a concise description of characteristics and purpose and how it adds value to Source.

Scale

This relates to both spatial scale (eg catchment/stream/point scale) and also time step information.

Principal developer

Use this area to reference:

• the original developer of the theory/specification
• original developer of the plug-in or antecedent model

Can be one or more persons or organisations.
eWater CRC should be acknowledged for anything developed during the eWater CRC (ie with eWater funding).

Scientific Provenance

The history of the science and implications for appropriate use.
Use this area to identify any new or untested science that should only be used for research or used with caution for decision making.

Version

State the Source version number or release date this content relates to. This is critical for tracking changes and archiving purposes.

Dependencies

What are the model requirements eg does it require a Storage to be present upstream.

Availability/conditions

Use this heading if the functionality is a plugin or requires any 3rd party software applications.

Structure & processes

NoteThis information should be available from the relevant specification.
NoteFor complex items use headings eg Theory, Structure, Process, Assumptions, Limitations
NoteGuidance on application can be provided in this section, ie what aspects of reality can it be used to represent, eg irrigation, and are there alternate configurations that can be used, eg fixed versus observed concentration. This does not include how to use it, just where and how to apply it.

Heading: Theory/Structure/Process/Assumptions/Limitations

(Pick the most appropriate heading or use several)

Sub-heading:

• Resource assessment
• Constraint phase
• Ordering phase
• Flow phase

Using each of the four sub-headings above, describe the processes that take place, in other words, how the science of the functionality works, using a text description supported by equations, graphs and other relevant illustrations as appropriate. State if the model is a simplification or extension of any existing models, and state the nature of the simplifications or extensions involved, including any effects on sensitivity. If any of the sub-headings are not applicable please state this explicitly rather than leaving it blank so we know it has been addressed.

Provide a schematic diagram if possible, showing the structure including inputs, outputs and processing paths. The Docs team can help produce this.

Submit a caption for the diagram, eg "Structure of the AWBM. You can see inputs (P), outputs (total runoff), internal variables (C1..C3, A1..A3). internal constants (K, KS)."
Please indicate which parameters can be manipulated or set by the user.
State any assumptions involved.
Indicate key limitations of the science with special reference to where it should/should not be used.
NotePut the derivation of the model (if applicable) into an appendix.

Data

Input data
Details on data are provided in the Source User Guide. Include here a brief note on what data is required and any additional information or recommendations on what is the most appropriate data to use eg is a minimum time period of historical climate data recommended (Note some recommendations will already be included in the Source best practice modelling guidelines).
Describe any data requirements not covered in the UG, eg no missing values.

Parameters or settings

Note Parameters are introduced in the UG. This section outlines acceptable parameter/data ranges and other relevant info.
What parameters and setting can the user control and what effect will this have? This is not the same as configuring the model initially (see Dependencies). For example, can users set the model to work in a "simple" mode of operation (ie fewer parameters, questions or less rigorous data requirements) or a "complete" mode, with "all questions" and a comprehensive data requirement.

For each parameter, state:

• parameter name
• what does the parameter do – what aspects does it control
• range of valid values if restricted by the software
• the default value for the parameter and the rationale for the default value
• the dimensions/units of the parameter
• the model's sensitivity to the parameter.

This information is best presented in a table:

If questions or yes/no, ticked/un-ticked boxes act as parameters, state what aspect of the model the ticked/unticked state or yes/no answer, or range of possible answers, effects.

As an example, one of the questions in the salinity model is "Is this a priority catchment"? If "yes", a certain multiplier is factored into the model. If "no" a different multiplier is used.

Output data

Briefly describe any outputs of the model. This may be about, for example, outputs that can be viewed in the Recording Manager.

Reference list

Include all cited references.

Bibliography

Include any key readings not cited within the text.