Modular Approach

An Approach for Modular Crop Model Development

In this page, a description of one recommended modular approach is given along with an example in which a simple crop and soil water model have been programmed as modules, using FORTRAN. The soil water and crop growth modules have been greatly simplified to allow us to focus on the approach instead of the relationships used in the modules. Thus, the model should not be used for other purposes. A listing of the FORTRAN code and input data files are also provided in an Appendix. The modules and an executable file can be downloaded to allow those who are interested in the approach to become more familiar with it.

Schematic of an overview of the modular structure

Module Definition and Structure

Reynolds and Acock (1997) and Acock and Reynolds (1989) proposed design criteria and rules for a generic modular structure for crop models. These include:

The modules should relate directly to real world components or processes that are common to all plants to be modeled.
Modules should represent a separate disciplinary function.
Input and output variables should represent measurable values;
Communication between modules should be solely via the input and output variables; and,
Modules should be validated independently of other modules.

These criteria have been used in the decision of what components of the model will comprise each module. Based on the first criteria, above, each module represents a physical function or process related to crop growth and consists of, as a minimum, a single FORTRAN subroutine, or a group of linked subroutines. These module processes are interdependent, but can be linked solely through a defined set of input and output variables, which are passed into and out of the modules as subroutine arguments.

The following guidelines, based on the approach of van Kraalingen (1995) and adapted by Kenig and Jones (1997) are proposed for the construction of modules. Each module should:

Read its own parameters;
Initialize its own variables;
Accept variables passed to it from other modules and the environment;
Pass variables that are computed within the module;
Own its set of state variables;
Compute rates of change for its state variables;
Integrate its state variables;
Write its own variables as output; and
Operate when linked to a dummy test program.

Thus, all data input, initialization of variables, rate calculations, integration calculations and output of data related to a specific function are handled within a single module. Modules can be run as a stand-alone model, when linked to a main driver program.

A Simple Crop-Soil Water Model Example

A simple model is presented to demonstrate an approach for modular model construction. The program consists of four main parts: the main program, plant growth module, soil water balance module and a weather input routine. A listing of the source code can be found in Appendix A. Although this program is written in the FORTRAN language, the modular approach described herein could be used with other computer languages as well.

The algorithms used in the plant and soil modules in the example model were intentionally kept very simple and are useful only to demonstrate the modular approach. The model is not intended to be used to accurately simulate actual physical conditions.

The criteria for generic modular structure developed by Reynolds and Acock (1997) and the specific guidelines for construction of a module were used in the development of the modules for the simple crop model which is used as our example. For larger, more complex models, it may be difficult to decide on how many modules to create. A few relatively large modules, using the criteria and principles above; would allow separation of these major components so that each could easily be replaced by other modules similarly structured, with exact matching of input and output variables. However, some of the modules may be components of larger system models or they may be made up of smaller modules, each of which could have the same criteria applied. Thus, the determination of modules is, to some extent, arbitrary.

Figure 1 illustrates the modular format used in the simple CROP model, in which each module has two or more of the following five components:

The ‘initialization’ section is used to input data and initialize variables and is called once per simulation.
The ‘rate calculation’ section computes process rates and rates of change of state variables based on conditions at the end of the previous day of simulation. This routine is called once per time step of simulation.
The ‘integration’ section updates state variables using the rates previously calculated.
The ‘output’ section is called once per day to generate daily output reports.
The ‘close’ section is called once at the end of simulation to close output files and generate summary reports.

Figure 1

The main program (MAIN.FOR) contains up to five calls to each module to accomplish the various components of processing. The dynamic flow of processing within the program is regulated with the DYN variable. Each module is called once at the beginning of simulation with DYN set equal to ‘INITIAL’, resulting in execution of the initialization portion of the module. During the daily time loop, each module is called three times: once each for rate calculation (DYN = ‘RATE’), integration calculations (DYN = ‘INTEG’), and for output of daily computed data (DYN = ‘OUTPUT’). A final call to each module is made to write summary output files and to close input and output files (DYN = ‘CLOSE’) after the simulation is complete.

The FORTRAN code used for directing calls to a module from the main program is presented in Figure 2. Figure 3 lists typical code used to control processing within a module.

Figure 2. Module Processing within Main Program

Figure 3. FORTRAN Code for Module Structure

In the example model, the main program calls the plant module, weather module and soil water balance module in turn to perform computations for each of the listed functions. Rate, integration and output sections are within the time step loop and the soil water and plant modules are each called three times per time step within this loop. The weather module is also called from within the time step loop, but only once per day in the rate calculations section.

The following sections detail the structure and content of the three modules which are included in this example model, i.e., the plant growth module, the soil water content module and the weather module.

Plant growth module (PLANT.FOR)

The plant growth module computes crop growth and development based on daily values of maximum and minimum temperatures, radiation and the daily value of two soil water stress factors, SWFAC1 and SWFAC2. This module also simulates leaf area index (LAI), which is used in the soil water module to compute evapotranspiration.

Initialization

Input variables, as listed in Table 1, are read from file PLANT.INP. File PLANT.OUT is opened and a header is written to this output file.

Table 1. Input Data Read for Plant Module
Variable Name	Definition	Units
EMP1	Empirical coefficient for LAI computation, maximum leaf area expansion per leaf	m²/leaf
EMP2	Empirical coefficient for LAI computation	—
fc	Fraction of total crop growth partitioned to canopy	—
fl	Specific leaf area	m²/g
intot	Duration of reproductive stage	degree-days
lai	Leaf area index	m²/m²
Lfmax	Maximum number of leaves	—
n	Leaf number	—
nb	Empirical coefficient for LAI computation	—
p1	Dry matter of leaves removed per plant per unit development after maximum number of leaves is reached	g
PD	Plant density	plants/m²
rm	Maximum rate of leaf appearance	leaf/day
tb	Base temperature above which reproductive growth occurs	°C
w	Total plant dry matter weight	g/m²
wc	Canopy dry matter weight	g/m²
wr	Root dry matter weight	g/m²

Rate calculations

The plant module calls three subroutines: PTS to calculate the effect of temperature on daily plant growth rate and rate of leaf number increase; PGS to calculate daily plant weight increase (g/plant); and LAIS to calculate increase in leaf area index.

In subroutine PTS, the growth rate reduction factor (PT) is calculated every day using the following equation:
where TMIN and TMAX are the minimum and maximum daily temperatures, respectively. Subroutine PGS calculates PG, the potential daily total dry matter increase (g/plant):
where SRAD is the daily solar radiation (MJ/m2) and PD the plant density (plant/m2). Y1 is obtained by:

where ROWSPC is the row spacing in (cm). The potential plant growth rate (PG) is limited by soil water stress (deficit or saturation) through SWFAC and temperature through PT.

The plant cycle is divided in vegetative and reproductive phases. The vegetative phase continues until the plant reaches a genetically determined maximum leaf number (Lfmax). During the vegetative phase, leaf number increase (dN) is calculated based on a maximum rate (rm) and a temperature based limiting factor (PT).

During reproductive phase, di, the difference between daily mean temperature and a base temperature (tb), is used to calculate the rate of plant development. Total rate of development towards maturity is accumulated as int.

Subroutine LAIS is called for both phases to compute the change in leaf area index (dLAI). During vegetative period, LAI increases as a function of the rate of leaf number increase. The potential rate is limited by soil water stress (both deficit and saturation), through SWFAC, and temperature, through PT. Its value is given by:
where PD is the plant density (plants/m²), EMP1 is the maximum leaf area expansion per leaf, (0.104 m²/leaf) and a is given by:
where EMP2 and nb are coefficients in the expolinear equation and N is the development age of the plant (leaf number).

After plant has reached the maximum number of leaves, LAI starts to decrease as a function of the daily thermal integral, di. The rate of decrease is given by:
where p1 is the dry matter of leaves removed per plant per unit development after maximum number of leaves is reached and SLA is the specific leaf area.

In the vegetative phase the assimilates are partitioned between canopy and roots (dwc and dwr) whereas in the reproductive phase all growth occurs in the grain (dwf). All whole plant weight increases (dw) are converted to area based values by multiplying by the plant density value (PD).

Integration

Changes to leaf area index (dLAI), plant weights (dw, dwc, dwr and dwf) and leaf number (dN) are integrated into the appropriate state variables (LAI, w, wc, wr, wf and N) at the beginning of the ‘integration’ section.When the accumulated value of the rate of development towards maturity (int) reaches a genetically determined value (intot), the grain is matured and the simulation is complete.

Output

Daily output is written to the PLANT.OUT file.

Close

The PLANT.OUT output file is closed.

Soil Water Balance Module (SW.FOR)

A single, homogeneous soil layer underlain by a relatively impervious layer is assumed for our example model. A simple water balance is used to update the soil water content on a daily basis using computed values of infiltration, evaporation, transpiration and drainage. The soil characteristics defined are soil water content at wilting point (WPp), field capacity (FCp) and saturation (STp) all in units of cm3/cm3; soil profile depth (DP in cm), daily drainage fraction (DRNp), curve number (CN) and initial soil water content (SWC_INIT in mm). The soil water module returns two parameters (SWFAC1 and SWFAC2) which express the effects of drought and excess soil water on crop growth rate. These factors vary from 1.0 (minimum stress) to 0.0 (maximum stress). In addition to soil characteristics and weather data, this module requires the value of leaf area index (LAI), which is computed in the plant module, to calculate potential evapotranspiration.