Classes

In the framework of object oriented programming, some generic classes were created. These classes are available as open source and will be used in future projects. Other classes are more specific and are not easy to transfer to other projects. These include the classes used for describing the architecture and the behaviour of the different organs.

Bifstream, derived from the STL class ifstream and bofstream derived from the STL class

ofstream. These classes handle input and output of binary streams taking into account the endian code of the used machine. The endian code describes how the machine handles the high and low bytes for the binary representation of variables. The endian code must be known before instancing a stream object. These classes are provided for sharing files created in machines with different endian code.

nxFile is a more effective file handling class, as the user don’t need to know about the endian code; it is determined automatically. This class is similar to the class ^QFile from Qt. In the Qt versions of the programs QFile was used instead of nxFile.

nxDate is a class for managing date in the Gregorian and the Julian calendars. The data input supports many formats and the output is also variable, e.g. dd/mm/yyyy or verbose version. A similar class, ^QDate is provided with Qt. This class has slightly different methods for handling the conversion Julian to Gregorian time and vice versa. In the Qt version ^QData has been used to maintain the same basis. Other classes are nxTime and nxDateTime for handling time in hours, minutes, seconds and milliseconds, and for day time respectively. Again, Qt provides the classes QTime and QDateTime, which were used in the Qt versions. The differences between the nx (NEXUS) versions and Q (Qt) versions are not really significant. The nx versions are used with the test versions of the software.

The class nxGeographics handles geographical co-ordinates and altitude. nxEphemeride

combines nxGeographics with nxDateTime (or QdateTime) for calculating sun positions and times of sunrise and sunset. The class nxSun is related to nxEphemeride.

The class nxPixel handles pixel co-ordinates and a series of attributes like colour. The

nxImage class is a container of nxPixel. These classes are used to generate graphical results.

The class nxPoint handles a point with x, y and z co-ordinates. The class nxVector is derived from ^nxPoint. ^nxPolygon is a list of ^nxPoint objects.

The class ^nxDocument handles files that are editable. The class ^nxCfg is derived from

nxDocument and handles files with the format:

# comments KEYWORD = VALUE

The classes nxConfig and nxSpecies are derived from nxCfg and handle the configuration and species files respectively.

The class nxImageViewer contains the graphical view application described above.

The class ^nxProject handles a generic project, and the class ^QPrjView handles the project window of the generic GUI. The class ^nxTable handles tabular data in the editor and the class

nxTextEditor handles editable test data..

The class nxSceneConverter contains the scene converting tool described above.

The class nxScene handles a group of plants as generated with AMAP. A nxScene can also contain only one plant.

The class ^nxTurtle describes a turtle object as described by DEN DULK (1989). The actual version is fixed to 46 sectors. A future version will handle a variable number of sectors.

The class nxRad handles the radiation balance of a scene. It contains the values for global, direct, diffuse and photosynthetically active radiation. The class nxTurtleRad is derived from

nxRad and works with nxTurtle to calculate the radiation balance from each turtle sector. The class ^nxMusc handles the radiation from the multi-scattering sub-model.

The class nxLine handles the information from the linetree files and reconstructs the tree architecture. It serves as a control class for the organ containers nxBranchList, nxSegmentList,

nxJunctionList and nxLeafList.

The class ^nxPlant handles a single plant with all its elements. The class ^nxOrgan defines the basic characteristics of each organic element.

The classes nxLeaf, nxSegment and nxJoint are derived from nxOrgan. The class nxBranch

describes a growth unit. The class nxPipe describes a sequence of nxBranch objects.

The class nxError is an error handling class. It delivers the error codes if an error can be identified.

Besides these classes, many mathematical classes and function templates were created that can substitute those provided by Qt or STL so that it is possible to create programs that are independent from them. These classes are mainly used in the text version of the programs mentioned.

The exact description of the classes and their members and methods will be available in form of on-line manuals. These will be posted initially at the server of the GWDG under http://www.gwdg.de/~ganzola/nexus.

Most classes have a number of undefined parameters in form of container classes of variable size. These are class templates (see 3.3) which are initialised with a base number of elements but that can be automatically expanded if more elements are used, or reduced if the number of elements decreases. With these “free” attributes, the classes can handle models with different parameters. The mean objective of the NEXUS project was to provide a possibility to interchange such sub-models. However, due to the problems with the parameterisation that represents an own problem, only the models provided by the original programs were tested.

The idea is to create a collection of sub-models in form of modules that can be changed by simple selection in the program’s menu.

In relation to the models used originally the following changes were made: First, all parameters whose values were fixed within the code were substituted with variables.

Constants were also defined separately in a special class called nxGlobal. All the constants are initialised with standard values, but it is possible to change their values for special cases. This can be achieved using parameter files like the species file described in section 3.2. Parameters that are normally variable are initialised with 0 and must be set by the user. Second, the function call for sub-models is kept general. The functions called provide the appropiate models according to the settings in the configuration files of the choices at run time.

NEXUS uses the event handling capacity of Qt to control the information flow between the programs. In this way, NEXUS can control the performance of HYDRA and GROGRA, which are programmed procedurally. GROGRA has already an interface for the socket connection, thus enabling a bi-directional information flow between, e.g., the radiation model (QMIR/QMuSc) and the growth engine (GROGRA). To use this, it is necessary to develop special L-systems that rely on this data flow. Although simple L-systems were tested, more complex models supporting radiation balance and water flow have not yet been realised.

The interconnection with the LIGNUM software (PERTTUNEN ET AL., 1998) and with AML (GODIN, 2000) is being realised in a parallel project by Helge Dzierzon at the University of Göttingen. The interconnection with HYDRA depends on the parameterisation and adaptation of that model to Quercus spc. and has not yet been completely achieved till now. The adaptation of HYDRA is part of a parallel DFG-funded project carried out by Dr. Michael Schulte at the University of Göttingen.