Module Interconnection.
Module varies between very simple and complex depending upon the amount of control the user builds into the module. Modules have three types of inputs and two types of outputs.
Observations.
Observations are traditionally measurements. Since the number and variety of field observations vary immensely, provision was built into the CRHM Platform to make them optional. An example of the use of this feature is precipitation. It can be daily or interval. To handle this transparently the obs module asks for both but makes them optional. Then when the model runs it accepts whatever is available and scales the values accordingly.
Observations may be available for every HRU or may only be collected at one point. CRHM modules can handle this. In modules the programmer has full control and in macro modules the last value of available observation data is duplicated for subsequent HRUs.
The concept of declared (module generated) observations was introduced. This allows the user to generate from the field (measured) observations declared (calculated) observations for every HRU. An example of this is the macro Slope_Qsi. This macro generates incoming short wave radiation on a sloping HRU from one measurement of incoming short wave radiation on the level to adjust for cloud cover using theoretically calculated clear sky short wave radiation.
Variable Inputs.
Variables are the quantities exchanged between modules. They are never optional as it assumed that modules always require these inputs. The fact that variable inputs are mandatory allows the CRHM Platform to automatically construct a model from individual modules.
Parameters.
Parameters are the constant spatial and physical coefficients required by the modules. They can with the same name exist independantly for every module in the model using them. However, if the values for a particular parameter are identical for two or more modules when the project is saved they will become basin parameters the next time the project is loaded.
It became evident that on occasions, parameters are not constant but need to vary over the course of a model run. An example being vegetation height. One method of handling this is to change the vegetation height from being a parameter to a variable input. This has the disadvantage of always requiring that the variable input height must always be satisfied by the output of another module. An alternative method is to leave height as a parameter and allow modules to change the parameters during the model run. This can easily be done using a macro module which can read the vegetation height from an observation file or calculate the crop height from an algorithm and change the parameter every interval.
AKA Screen.
Despite all the flexibility built into Observations and Variables all model requirements could not be met. Some examples follow.
- Different Time Units. - Various melt models were implemented. Some calculate melt every interval and others over a day. It was very difficult to handle the output of the different melt modules without customising the modules that received their output. The AKA screen allows the normal connections between modules to be broken and custom modules to be inserted to convert outputs to match the requirements of the next module. This could be mean a change in units or interval, day to interval or vice versa.
- Modules requiring enhanced observations.
- User Name Preferences. - Simple observation names may be renamed. E.g. "t" can be renamed "T" etc.
CRHM Criteria for linking modules to create a model.
The order that modules appear in the flow diagram is the order that they are executed. If a module output is used in an interval before the module is executed the variable value used will be the model initial value in the case of the first interval or the previous interval value there after. State variables are handled as a special case. Their values are continuous and there last interval value is often used to calculate their new value for the current interval. Examples are albedo and SWE.
- Modules are arranged by variable input requirements.
- State variables are ignored in the arrangement of the modules. This may be overridden using the setpeer command if neccessary.
- Modules are arranged by declared observation requirements.
- Parameters never influence the arrangement of modules.
- The setpeer command delays the loading of a module until the declared variable input is available (i.e. calculated for current interval).