Technical Manual

[ Return to Technical Manual Index ]


C++ Class Descriptions

This page contains written descriptions of the most prominent classes in the object-oriented version of RHESSys. In addition, there are links to the header files of each class and links to the member functions that we detail here. Not all member functions are described on this page due to the large volume of functions we were dealing with here.

Index to class descriptions:

 


class base_station

Description:

The base_station class is used to manage temporal sequences of climate data for use by the physical model in its simulation. This climate data can be broken up into four categories: yearly, monthly, daily, and hourly. Each category is represented by a corresponding class.  Objects of all these climate classes are created dynamically by the base_station.  The base_station stores pointers to all these classes and climate information can only be accessed by requesting this information from the controlling base_station.

Notable Member Functions:

Notes:

There are three classes that represent climate data: daily_climate, hourly_climate, and climate.  Both the yearly climate and monthly climate are instances of class climate, because the information stored in both is of the same form and the functions on both climates have the same form.

Also, our current method of destroying the base_station is a rough fix.  The problem is described in detail here.

Finally, future developers may want to alter the base_station implementation to support linking to a climate model.  More information on this can be found here.

 

Class world

 Description:

The world class is the highest level of the spatial hierarchy, containing one or more basins (which themselves contain hillslopes, zones etc). No physical or ecological variables are stored or simulated at the world level; the world class is simply a collection of basins. The world class also contains the single default_collection object, a pointer to which is passed down the chain of constructors as the model is created.

Notable Member Functions:

Notes:

 

class command_line

Description:

This class contains all the information passed to the program on the command line. This includes filenames for input and output (the world file, routing list file and tec file) as well as various flags. The start date and end dates given in the world file may be overridden by command line options, and there are options to output time series for basins, hillslopes, zones, patches and canopy strata. For more information, see the command line options page.

Notable Member Functions:

Notes:

 A pointer to the command line is kept by all objects of type basin, hillslope, etc because they all need to access the flags at runtime (notably the 'verbose' level and the 'grow' flag). In the C model this was accomplished by passing a command_line pointer down the hierarchy with each _daily_I, _hourly and _daily_F call. The mew method should provide an slight increase in speed at the expense of each object being fractionally larger.
The command_line object is a local variable of the main() function.

 

class snowpack

Description:

A snowpack is an object statically contained within a patch, representing the presence of snow. Each patch has exactly one snowpack whose variables are read in and out as part of the world file. Snow can have significant effects on the radiation balance and hydrology of a patch.

Notable Member Functions:

Notes:

Several variables of the snowpack class are modified - by accessor functions - in patch_daily_F and patch_hourly.

 

 class tec

Description:

"Temporal Event Control": This class (of which there is only one instance - created in main()) drives the model forwards hour-by-hour and day-by-day, also handling any special events as they occur. Its behaviour is governed by the tec file, to which it maintains a pointer. It keeps track of the current date as the simulation progresses.

Notable Member Functions:

Notes:

 

 class tec_entry

Description:

This class describes an individual tec event; i.e. a single line of the tec file. It has only two member variables: a date object, which specifies when that event is to occur, and a character array containing a textual description of the event.

Notable Member Functions:

Notes:

 The possible events given by the 'command' member variable are:

Event name

Description

print_yearly_on, print_yearly_off
print_monthly_on, print_monthly_off
print_daily_on, print_daily_off
print_daily_csv_on, print_daily_csv_off
print_hourly_on, print_hourly_off

Controls printing to output files. The command line determines which objects (individual patches, zones etc) are printed… the tec file determines when they are printed.

roads_on, roads_off

This manipulates the state of the 'roads' flag; ie whether the effects of roads should be simulated. A 'roads_on' event in the middle of the simulation will have the effect of the road being 'built' at that date.

redefine_strata

This causes one or more canopy_stratum objects to be totally redefined according to a given file - this can be used to simulate a sudden loss of vegetation, for example, or any other 'forcing' event.

output_current_state

This event causes the current world state to be dumped to a new world file.

none

Does nothing

 

 class default_collection

Description:

This class is a container for all the default files in a given run of the model. It contains five objects: a basin_default_array, a hillslope_default_array, a zone_default_array, a patch_default_array and a stratum_default_array. Each of these classes are themselves containers which manage all the default files available for their particular spatial level.
There is only one instance of default_collection; it is a member of the world class.

Notable Member Functions:

Notes:

See the default_collection diagram for a visual explanation of this structure.

 class default_array

Description:

This is an abstract base class for the basin, hillslope, zone, patch and stratum default_array classes. It implements the ability to read and store a list of filenames, which all of these classes require.

Notable Member Functions:

Notes:

This is an abstract class and so there are no objects of type default_array; it is used only as a base class for the basin_default_array, hillslope_default_array, zone_default_array, patch_default_array and stratum_default_array classes. See the default_collection diagram for a visual explanation of the structure.

Classes: basin_default_array, hillslope_default_array, zone_default_array, patch_default_array and stratum_default_array

Description:

These classes are all similar in structure, and are each used to maintain a list of default objects for their particular spatial level. The default objects themselves are very different. In this class description, level refers to either basin, hillslope, zone, patch or stratum. These classes only have one member variable (aside from the two inherited from the default_array class), namely a pointer to an array of default objects for their individual level.

Notable Member Functions:

Notes:

See the default_collection diagram for a visual explanation of the structure.

The RHESSys framework partitions the lanscape into a
hierarchical structure as shown in Figure.  Please see
Introduction section of this manual.
The landscape representation and parameters associated with each
level of the hierarchy are described in the worldfile which is
input into RHESSys.

class basin

Description:

Basins define drainage basins.  Explicit routing is organized
at this level to produce streamflow within the basin stream
network.  Basins also serve as aggregating units such that
basin output may be total landscape photosynthesis, where
photosynthesis is actually calculated at the sub-basin (patch)
level.

Public member functions of the Basins class:

class hillslope

Description:

Hillslope define areas which drain to a single point or stream
reach.  Hillslopes also denote areas of similar radiation.
Although radiation processing is done at the zone level,
similarity in radiative environment is inherited through the
preceding hillslope level.  TOPMODEL redistribution of soil
moisture is done at the hillslope level.  Like basins,
hillslopes can be used to aggregate sub-level processes.

Public member functions of the Hillslope class:

class zone:

Description:

Zones denote areas of similar climate and zone objects store
climate variables such as radiation, temperature, etc.  Each
zone is linked to an input climate state.  Data from this
station such as precipitation and temperature is modified
based on zone elevation, slope and aspect relative to the
base station.  Zone processing also generates climate
data not available from base station.

Public member functions of the Zone class:

class patch:

Description:

Patches represent the highest resolution spatial unit.  Soil
moisture is done at the patch level.  Patch level variables
include fluxes such as infiltration and storages such as
unsaturated zone soil moisture.  The patch level partition must group together areas of similar soil moisture since soil
moisture driven processes such as runoff production occur at
this level.  The redistribution of soil moisture also occurs at
this level. The spatial resolution of the canopy stratum is also
defined by the patch partitioning.  Canopy stratum are a
separate object type but they define vertical rather than
spatial layers.  Patches must, therefore, also group together
areas of similar canopy cover.

Public member functions of the Patch class:

class canopy_stratum:

Description:

Canopy strata define vertical layers above the patch. 
Processes such as photosynthesis and transpiration
are modeled at the canopy stratum level. Canopy
strata have the same spatial structure as patches.
Unlike other levels, however, canopy strata define
multiple vertical layers.  Each stratum
corresponds to a different layer such as overstory or
understory in the canopy structure.

Public member functions of the class Canopy_Strata: