Groups and Sructures (04/07/08)

CRHM Platform

Groups and Sructures.

Group.   A collection of modules executed in sequence for all HRUs.

   After using CRHM for a while, it was found to be inconvenient to always handle the individual modules.  To overcome this groups were introduced.  A group module,  is a collection of modules which can be used in place of specifying the individual modules.  When the group is defined the modules must be specified in the correct execution order.  Use of groups and a relevant naming convention allow models to be easier implemented and understood.  Unecessary detail can be hidden from the flow diagrams and documentation. The larger building blocks simplify the implementation of larger models.

    Since different groups can have the same variable outputs in a model it is necessary to enhance the output variable names so that they do not conflict with one another. Variable names can already be long to be meaningful, a short suffix seemed to be the best way to differentiate the repeated names and the root name still to be recognizable.  Suffix @A, @B, @C... are used where @A is used for outputs of the first group, @B is used for the next group etc.

    Group application:

  1. If  groups are defined with the same modules,  it is possible to execute the models in parallel using different parameters or driving observations.
  2. If groups are defined as different models,  it is possible to execute the models in parallel using identical parameters and driving observations to check different responses.

Structure.  A parallel collection of modules.  Only a selected one of them is executed for any HRU in a time step.

    Again after using CRHM it was found that it was not always desired to execute the same module for every HRU.  A structure handles this situation.   The selection of the module for every HRU can be programmed statically, e.g. example 1. below or dynamically by using a preceding module to select the module to be used for the current time step, e.g. example 2. below.

    Since structures can have the same variable outputs in a model it is necessary to enhance the output variable names so that they do not conflict with one another. Variable names can already be long to be meaningful, a short suffix seemed to be the best way to differentiate the repeated names and the root name still to be recognizable.  Suffix @a, @b, @c... are used where @a is used for outputs of the first structure, @b is used for the next structure etc.  Groups use an upper case suffix while structures use a lower case suffix.

    Structure application:

  1. Comparison of algorithms;  it is possible to specify a different module, say from evap, evapD, ShuttleWaite and ShuttleWaiteD for every HRU and track the different responses.  Some of the modules, say evap,  may be used more than once with parameters selecting Granger, Priestley-Taylor and Penman-Monteith giving more combinations.
  2. Sometimes HRUs require diverse modules to be representative of the unit.  An example would be forested and open farmland.  By using the structure capability a general model can be customised to handle individual HRUs differently.
  3. Sometimes HRUs change their characteristics due to excess water or lack of it.   Using a structure,  the module selection can be dynamically changed.  If an HRU can experience dry spells, moderate rainfall and very wet conditions with flooding then it might be desireable to treat it using a grasslands module, wetlands module or a slough module respectively.  The decision about which module to use would be made by a preceding module based upon the availability of moisture.

AKA Interaction with Groups.

    In the normal useage of AKA in non-group models,  the variables and observations are addressed uniquely by  specifying the varable or observation and the module.  However, with groups,  variables and observations all are referenced by the group name.  This lack of resolution means that the source and destination of variables and observations cannot be defined precisely.  For example, if the user attempts to change say Qsi to the declared observation Qsi#, all occurrences of Qsi would be changed even the input to the module generating Qsi#, causing a loop.   To prevent this from happening,  if an attempt is made to change an input of a module to the same name as one of its outputs, it will be ignored.

    Declared observations, e.g. Qsi# do not have future data available to be able to generate any daily function, i.e. mean, max etc.  CRHM detects these calls and leaves the observation as a simple observation, i.e. Qsi.  In most situations this is the most desireable selection anyway.