Model Concepts.
A CRHM model is constructed out of Modules - the basic building blocks implementing the model algorithms. The modules depend upon the transmission of information between themselves and the outside world. The information must be processed in an orderly manner - so the order or sequence of the modules in the execution chain is important. The model information breaks down into three groups.
- Parameters - physical parameters like elevation, area, vegetative/agricultural use etc. which are used in the module algorithms. Assumed to be constants. Also used as initial values for variables.
- Observation - meteorology information providing the driving force of the model. Source is data files. Could also be generated data.
- Variables - state variables and value variables which store the states of the modules and provide the interchange of values between the modules.
Organisation.
Sequence or Order of modules.
This is determined from the variable flow through the model. When a specific module requires an input variable from another module it follows that the module generating the required variable must appear earlier in the chain of execution of modules. Within the CRHM platform there is logic that will automatically order the modules of a model according to their variable hierarchy.
Parameters must be defined in every module they are used in. The CRHM platform has the capability of grouping parameters with the same name and with identical values for each HRU together and calling them basin parameters. Changing the value of a basin parameter changes the value for every module sharing the parameter.
Observation data is assumed to be available to all modules from the beginning of a time period till its end. The module order is independent of the observations.
Problems with the simple concept.
When models are only run over a short time period of time, parameters can be assumed to be constant. However, most parameters gradually change with time and can change dramatically with the season. They in fact become variables.
Observations are the driving force of the model. However, they are not constant over the area being modelled as the observations have to be interpolated to determine actual values for the individual HRUs of the model. The observations may also have to be corrected for the elevation of the HRU.
Solution.
The operation of parameters and observations were extended to handle the shortcomings outlined above.
Parameters.
Since operational parameters vary with time and season, it was decided to make them input variables with the proviso that if they could not be satisfied by another module output they would link to a constant parameter of the same name defined within the current module. This has many advantages. Modules can inititially be tested using constant parameters when the variable name is unsatisfied. Later they can be inserted into a functional model and the parameter variable satisfied by an earlier module output of the same name as the parameter.
Observations.
Another category of Observation was created. This combines the properties of an observation with a variable. A module can create an observation which can satisfy the observation input requirement of a later module. However, if a file observation of the same name is available, it will override the module generated observation. A distinguishing feature of a module generated observation is that it determines the order of the modules in the model as if it was a normal variable.
Observation dimensions.
Some ambiquity arises with respect to observation dimensions which is made more difficult by the fact that observations generated by modules are normally dimensioned NHRU.
File observations are normally dimensioned NOBS. In practice most often there is only a single observation (not a value for each HRU). However, the module call to declreadobs returns at runtime the actual number of observations available and the programming logic can be designed to handle fewer values. In the case of macro modules the observation access is limited to the maximum number of legal values.
File observations are normally dimensioned as NOBS. The value of NOBS is not normally of much use as it returns the value for the observation with the maximum number of observations.