AirTemperature: Extensible Software Library to Generate Air Temperature Data

1. Introduction

A large number of existing agricultural and ecological models have been implemented as software that cannot be well maintained or reused, except by their authors, and therefore cannot be easily transported to other platforms (e.g., [1, 2]). In order to possibly include legacy data sources into newly developed systems, object-oriented development has emerged steadily as a paradigm that focuses on granularity, productivity, and low maintenance [3]. Several papers have been recently published in agroecological journals [4–10] targeting at reusable dynamic link libraries either within the Microsoft.NET framework (http://www.microsoft.com/NET/) or using the SUN Java platform (http://java.sun.com/). Such solutions reflect a style of programming referred to as component-oriented programming that has become the leading methodology in developing systems in a variety of domains, including agroecological modeling [2]. Although different definitions of component do exist in the literature [11–13], a component is basically a discrete software unit which makes available specific functionalities, and it can be presented as a black box that provides access to its services through a defined interface. The component development paradigm is to make the construction of a software as plugging together independent components.

In the context of the agricultural and environmental modeling community, alternative frameworks are available to support modular model development through provision of libraries of biophysical modeling modules, as well as reusable tools for data manipulation, analysis, and visualization [14]. Various object- and component-oriented solutions have approached the issue of agricultural and environmental modeling, such as maize irrigation scheduling [15], multiple spatial scales ecosystems [16], greenhouse control systems [17], and households, landscape, and livestock integrated systems [18]. In the same perspective, we have approached the weather generation issue. Long records of weather data are in fact needed for evaluating agricultural management scenarios in natural resource models (e.g., [19, 20]). Weather inputs required by natural resource models include air temperature, precipitation, solar radiation, wind speed, and dew point temperature. Synthetic weather sequences are needed if long-term measured data are not available, measured data contain missing records, or collection of actual data is cost or time prohibitive or when necessary to simulate impacts of future climate scenarios. Weather simulation models (or weather generators) are commonly used to generate synthetic weather records for use in the study of crop growth and development, water availability, soil erosion, climate change, and other domains (e.g. WST, http://www.wcc.nrcs.usda.gov/climate/wst_fact.html). Several weather generators are available in the form of ready-to-use, user-oriented tools, implementing specific solutions to the basic problem of generating one or more weather element. Such an approach is, however, ineffective for developers of custom applications, who have to reimplement the set of equations within modeling applications of various complexity. Moreover, because of either the empiricism or the alternative inputs required by different generation approaches, it may be desirable to compare different methods in case-specific applications in order to provide reliable weather data for case-specific applications.

Reusability in weather generation can be efficiently achieved by capturing the domain knowledge currently available (i.e., weather models already developed and tested) and making it available in software components. This is the reason why component-oriented tools have been recently developed to fit this need, that is, ET for calculating evapotranspiration and related variables [5], GSRad for estimating synthetic values of solar radiation [6], Rain [4] for generating precipitation data, and Wind [9] for generating wind speed data. The components mentioned provide a set of alternate models to estimate variables specific for the domain targeted and are implemented using a software architecture which promotes reusability [21]. The present study focuses on the modeling of air temperature that, to the best of the authors’ knowledge, has not yet encapsulated into component-based solutions. Air temperature values are essential to plant growth and the development of organisms. One problem in simulating air temperature is that measured daily maximum and minimum air temperatures are often slightly skewed and not normally distributed in each month. So, generating air temperature from the normal distribution may result in physically improbable values (especially extreme hot temperatures). Although the assumption of normality is often contradicted [22], the normal distribution (variously interpreted and corrected) is the reference distribution of all the approaches currently used to generate air temperature data. Weather generators (including Cligen [23], WGEN [24], USCLIMATE [25], LARS-WG [26], ClimGen [27], and CLIMAK [28]) are commonly used to generate daily maximum and minimum air temperatures in agroecological projects. Generation of maximum and minimum air temperatures is also useful for modeling applications that require estimates of hourly temperature throughout a day. A best guess is made by assuming that minimum air temperatures normally occur close to sunup and maximum air temperatures a few hours after solar noon (e.g., [29]). Moreover, relationships between air relative humidity and air temperature can be rearranged as an association of the dew point temperature with the two daily extremes (e.g., [30]). Disaggregation from daily to hourly records and estimation of dew point air temperatures are both largely based on empirical relationships.

This paper illustrates how well-known air temperature generation approaches have been implemented into a software component (namely, AirTemperature). The procedures implemented in the component, the scientific background, some principles of usage, and source code are extensively documented in hypertext help files. The paper describes the implementation features that guided the development of AirTemperature, followed by a discussion on the main component features.

2. Background

The modeling background implemented in AirTemperature, fully documented in the online help file, is not reproduced hereafter. The main features are only briefly summarized. All these models are published in peer-reviewed journals; details about their development and the applications in case studies are reported in the referenced papers.

2.1. Daily Generation of Air Temperature

The generation of daily maximum (, C) and minimum (, C) air temperatures is considered to be a continuous stochastic process, possibly conditioned by the precipitation status of the day. Three methods are implemented for generating daily values of and . The multistage generation system is conditioned on the precipitation status with both approaches from Richardson [31] Danuso and [28]. Residuals for and are computed first, then daily values are generated independently (Richardson-type) or with dependence of on (Danuso-type). A third stage, that adds an annual trend calculated from the Fourier series, is included in Danuso-type generation. The Richardson-type approach accounts for air temperature—solar radiation correlation. A third approach [32] generates and independently in two stages (daily mean air temperature generation first, and next), making use of an autoregressive process from mean air temperatures and solar radiation parameters.

2.2. Hourly Generation of Air Temperature

Daily values of and are used to generate hourly air temperature values, according to alternative methods. Sinusoidal functions are largely used to represent the daily pattern of air temperature. Six approaches, by Campbell [33], Goudriaan and van Laar [34], Ephrath et al. [35], Porter et al. [36], Stöckle [29], and Gracia et al. [37] are used to generate hourly values from daily maximum and minimum temperatures. A further approach, proposed by Dumortier [38], derives hourly air temperatures from the daily solar radiation profile. Mean daily values of dew point air temperature are estimated via empirical relationships between and and other variables [30, 39–43]. A diurnal pattern (hourly time step) of dew point air temperature is also modeled via two alternative methods [35, 44].

3. Software Features

3.1. Input and Outputs

The outputs produced by AirTemperature and the inputs (variables and parameters) required by the models implemented are listed in Table 1.

Table 1: List of all the inputs and outputs of the models implemented into AirTemperature component. Outputs are arranged by an identification number (ID) assigned to input variables and parameters used to calculate each output.

3.2. Design

The software design promotes reusability by limiting dependencies and providing a semantically rich, public interface. By allowing extensibility of approaches in a straightforward way, it also allows third parties to add new equations and the comparison of alternate air temperature models. This design [21] combines architectural traits that maximize transparency, extensibility, scalability, traceability, and data quality control. The same design has been already used in the development of several components for agrometeorology, agromanagement, crop and soil water/nitrogen/chemicals simulation, model evaluation, and soil pedotransfer functions (http://www.apesimulator.org/help.aspx). The Unified Modeling Language (UML) component model of AirTemperature (Figure 1) shows the discrete units and their dependencies.

Figure 1: Generic component model used for AirTemperature. The Preconditions component allows the implementation of the design-by-contract approach and provides the base classes to build and make accessible the component ontology. The separation of data types (domain classes) and interfaces from models (strategies) in two discrete units allows the implementation in clients of the design pattern Bridge, which facilitates replacement of model components.

3.3. Architecture

AirTemperature architecture allows extending data-types and adding new modeling solutions without the need of recompilation of the core component.

The component implements Strategies, which are alternative implementation of air temperature models. Each model is computed via one of such discrete units, which encapsulates the algorithm, the test of pre- and postconditions, and parameters declaration (if any). The component implements Composite Strategies (built using two or more strategies) and Context Strategies, that is, model units which implement logic to select among the strategies associated, for example, based on the inputs available. Extension is made possible by the definition of the common interface IAirTDataStrategy, which must be implemented by all strategies. The UML class diagram (Figure 2) shows the classes and interfaces which allow extending the component via the Composite and Strategy design patterns.

Figure 2: Class diagram illustrating the specific implementation of the design patterns Composite and Strategy.

The design-by-contract approach [45] is used, requiring pre- and postconditions (e.g., maximum daily air temperature > minimum daily air temperature) to be respected. Any application using AirTemperature can hence test inputs for a possible violation of preconditions, and it can check postconditions (http://agsys.cra-cin.it/tools/preconditions/help/). The Model Component Explorer (MCE, http://agsys.cra-cin.it/tools/, page “Applications”, then “MCE”) is an application to discover parameters, inputs, and outputs of each model and to browse the component ontology by inspecting data-types (called Domain Classes) and the component interfaces. AirTemperature is one of the core components of the weather generator CLIMA [8].

3.4. Distribution

AirTemperature is distributed via a Software Development Kit that includes the source code of Visual Studio.NET projects demonstrating how to extend and reuse the component. Also, hypertext files are made available, documenting the models implemented (http://agsys.cra-cin.it/tools/airtemperature/help/) and the code of the software component (http://agsys.cra-cin.it/tools/airtemperature/codedoc/). The project source code of sample web services (http://agsys.cra-cin.it/webservices/airtemperature/) and web application (http://agsys.cra-cin.it/webapplications/airtemperature/) is also provided. The component requires the framework Microsoft.NET 2.0 (or newer) installed.

4. Remarks

It is widely accepted that research in agroecology must be supported by the state-of-the-art modeling. Model development and operational use require, however, the capability of quickly accessing knowledge in different domains, selecting and comparing alternate modeling options, and making use of such knowledge via computer-based tools. The modeling system of AirTemperature can be considered a way to share knowledge, making it available in an operational tool. To date, although the use of software model frameworks has improved the maintainability of complex simulation systems, effective reuse of discrete units in the domain of biophysical models is still mostly a goal rather than an achievement. The architecture of AirTemperature decouples data from weather models, providing a semantically rich interface in framework-independent implementation, thus facilitating reuse and independent extensibility by third parties.

Acknowledgments

Laura Carlini is acknowledged for her contribution to the initial implementation. This publication has been funded under the SEAMLESS integrated project, EU 6th Framework Programme for Research, Technological Development and Demonstration, and Priority 1.1.6.3. Global Change and Ecosystems (European Commission, DG Research, contract no. 010036-2).