# AirTemperature: Extensible Software Library to Generate Air Temperature Data

Authors: Marcello Donatelli; Gianni Bellocchi; Ephrem Habyarimana; Simone Bregaglio; Bettina Baruth
Journal: SRX Computer Science
 (2010)

---

## Abstract

The development of a set of reusable libraries to support custom applications has become a goal in biophysical modeling projects. This is true for weather modeling as well.AirTemperature is a software component providing a collection of deterministic and stochastic approaches to generate atmospheric temperature data on daily and hourly time steps. Data generated on a daily time step consist of maximum and minimum air temperature and dew point temperature. Hourly estimations include air and dew point temperatures. The software design allows for extension of the models implemented without recompiling the component. The component, inclusive of hypertext help documentation files, is released as compiled .NET2 version, allowing application development in either programming environment. A sample client and a sample extension project using AirTemperature are provided as source code. A sample Web service and a Web application are also developed as examples of possible use of the component.


---

## Body

## 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 inAirTemperature, 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 (Tmax, °C) and minimum (Tmin, °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 Tmax and Tmin. The multistage generation system is conditioned on the precipitation status with both approaches from Richardson [31] Danuso and [28]. Residuals for Tmax and Tmin are computed first, then daily values are generated independently (Richardson-type) or with dependence of Tmax on Tmin (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 Tmax and Tmin independently in two stages (daily mean air temperature generation first, Tmax and Tmin next), making use of an autoregressive process from mean air temperatures and solar radiation parameters.


### 2.2. Hourly Generation of Air Temperature

Daily values ofTmax and Tmin 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 betweenTmax and Tmin 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].


## 2.1. Daily Generation of Air Temperature

The generation of daily maximum (Tmax, °C) and minimum (Tmin, °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 Tmax and Tmin. The multistage generation system is conditioned on the precipitation status with both approaches from Richardson [31] Danuso and [28]. Residuals for Tmax and Tmin are computed first, then daily values are generated independently (Richardson-type) or with dependence of Tmax on Tmin (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 Tmax and Tmin independently in two stages (daily mean air temperature generation first, Tmax and Tmin next), making use of an autoregressive process from mean air temperatures and solar radiation parameters.


## 2.2. Hourly Generation of Air Temperature

Daily values ofTmax and Tmin 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 betweenTmax and Tmin 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 byAirTemperature 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 intoAirTemperaturecomponent. Outputs are arranged by an identification number (ID) assigned to input variables and parameters used to calculate each output.
Variables/parametersUnitOutput IDOutput variablesTd(hr): hourly dew point air temperature°C1Td: daily dew point air temperature°C2Tmax: daily maximum air temperature°C3Tmin: daily minimum air temperature°C4TTk: yearly trend of daily maximum (T= Tmax) and minimum (T= Tmin) air temperatures on dry (k= 0) or wet (k= 1) days°C5χ(d)k0,k(j): daily standardized residual of maximum (j= 1) and minimum (j= 2) air temperatures on dry (k= 0) or wet (k= 1) days—6Thr: hourly air temperature°C7Input variablesRHmax: daily maximum relative humidity%2RHmin: daily minimum relative humidity%2dT: day-to-day difference of mean air temperatures°C3, 4dTsd: standard deviation of day-to-day difference of mean air temperatures°C3, 4G¯: monthly average of daily global solar radiation on a given surfaceMJm-2d-13, 4, 6Gx(d): daily global solar radiation at ground levelMJm-2d-13, 4, 6Z: site elevation above sea levelm2Tm(c): mean air temperature of the coolest month°C2Tm(d): mean air temperature of the warmest month°C2Gh(hr): hourly global solar radiation on a horizontal surfaceMJm-2 d-17d: day number into year—3, 4, 5Si: precipitation occurrence of current day—3, 4, 5, 6DL(d): day lengthh7sr(d): time of sunriseh1, 7Tmax: daily maximum air temperature°C2, 7Tmin: daily minimum air temperature°C2, 7T¯Tk0,k: monthly average of daily maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days°C3, 4, 6σTk0,k: monthly standard deviation of daily maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days°C3, 4, 6ATk: annual mean maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days°C3, 4, 5Input parametersBTk: semiamplitude of the first harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5CTk: phase shift of the first harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5DTk: semiamplitude of the second harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5ETk: phase shift of the second harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5RRnn: monthly autocorrelation coefficient for minimum air temperature residuals, with time lag of 1 day—3, 4RRnx: monthly correlation coefficient between minimum and maximum air temperature residuals—3, 4SRT: monthly standard deviation of the residuals from the trends of maximum (T= Tmax) and minimum (T= Tmin) temperature both on dry and wet days°C3, 4R1n: standardized residual of minimum air temperature of the previous day—3, 4Tmax(d-1): maximum air temperature of the previous day°C3, 4, 7Tmin(d-1): minimum air temperature of the previous day°C3, 4, 7N: number of days in a month—3, 4N(d): number of dry days in a month—3, 4N(w): number of wet days in a month—3, 4bT: scaling factor—3, 4k0: dry/wet days separation option—3, 4, 6Ak0,k: 3×3 matrix function of the lag-0 serial- and cross-correlation coefficients of the residuals on dry (k= 0) or wet (k= 1) days—3, 4, 6Bk0,k: 3×3 matrix function of the lag-1 serial- and cross-correlation coefficients of the residuals on dry (k= 0) or wet (k= 1) days—3, 4, 6χ(d-1)k0,k(j): standardized residual of maximum (j= 1) and minimum (j= 2) air temperatures and global solar radiation (j= 3) on dry (k= 0) or wet (k= 1) days for the previous day—3, 4K0: daily dew point air temperature correction factor°C2a, b, c, d: empirical parameters of model Hubbard for daily dew point air temperature-, -, -, °C2A, B, C, D, E, F, G: empirical parameters of model of Kimball et al. for daily dew point air temperature-, -, -, -, -, -, °C2EF: evaporative demand—2A1,B1,C1,D1,E1: empirical parameters of model Linacre 1 for daily dew point air temperaturem-1, -, -, -, °C2A2,B2,C2,D2: empirical parameters of model Linacre 2 for daily dew point air temperature-, °C-1, -, °C2hrdv: hour of the day for maximum air temperature to occurh7Tmin(d+1): minimum air temperature of the next day°C7sr(d+1): time of sunrise of the next dayh7ss(d+1): time of sunset of the next dayh7T(ss(d-1)): air temperature at sunset of the previous day°C7aslp: slope coefficient—7LSH: hour of maximum solar heighth7p: delay of the maximum air temperatureh7Tk: air temperature increment°C7TC: nocturnal time coefficienth7k: shift factor—7AP, BP, CP: empirical parameters of model of Porter et al. for hourly air temperatureh, h,-7AS, BS, CS, DS, ES: empirical parameters of model Stöckle for hourly air temperature-, -, -, -, -7Td(d+1): dew point air temperature of the next day°C1Td(max): maximum dew point air temperature°C1


### 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 forAirTemperature. 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 implementsStrategies, 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 patternsComposite 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.


## 3.1. Input and Outputs

The outputs produced byAirTemperature 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 intoAirTemperaturecomponent. Outputs are arranged by an identification number (ID) assigned to input variables and parameters used to calculate each output.
Variables/parametersUnitOutput IDOutput variablesTd(hr): hourly dew point air temperature°C1Td: daily dew point air temperature°C2Tmax: daily maximum air temperature°C3Tmin: daily minimum air temperature°C4TTk: yearly trend of daily maximum (T= Tmax) and minimum (T= Tmin) air temperatures on dry (k= 0) or wet (k= 1) days°C5χ(d)k0,k(j): daily standardized residual of maximum (j= 1) and minimum (j= 2) air temperatures on dry (k= 0) or wet (k= 1) days—6Thr: hourly air temperature°C7Input variablesRHmax: daily maximum relative humidity%2RHmin: daily minimum relative humidity%2dT: day-to-day difference of mean air temperatures°C3, 4dTsd: standard deviation of day-to-day difference of mean air temperatures°C3, 4G¯: monthly average of daily global solar radiation on a given surfaceMJm-2d-13, 4, 6Gx(d): daily global solar radiation at ground levelMJm-2d-13, 4, 6Z: site elevation above sea levelm2Tm(c): mean air temperature of the coolest month°C2Tm(d): mean air temperature of the warmest month°C2Gh(hr): hourly global solar radiation on a horizontal surfaceMJm-2 d-17d: day number into year—3, 4, 5Si: precipitation occurrence of current day—3, 4, 5, 6DL(d): day lengthh7sr(d): time of sunriseh1, 7Tmax: daily maximum air temperature°C2, 7Tmin: daily minimum air temperature°C2, 7T¯Tk0,k: monthly average of daily maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days°C3, 4, 6σTk0,k: monthly standard deviation of daily maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days°C3, 4, 6ATk: annual mean maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days°C3, 4, 5Input parametersBTk: semiamplitude of the first harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5CTk: phase shift of the first harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5DTk: semiamplitude of the second harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5ETk: phase shift of the second harmonic for yearly trends of maximum (T= Tmax) and minimum (T= Tmin) air temperature on dry (k= 0) or wet (k= 1) days—3, 4, 5RRnn: monthly autocorrelation coefficient for minimum air temperature residuals, with time lag of 1 day—3, 4RRnx: monthly correlation coefficient between minimum and maximum air temperature residuals—3, 4SRT: monthly standard deviation of the residuals from the trends of maximum (T= Tmax) and minimum (T= Tmin) temperature both on dry and wet days°C3, 4R1n: standardized residual of minimum air temperature of the previous day—3, 4Tmax(d-1): maximum air temperature of the previous day°C3, 4, 7Tmin(d-1): minimum air temperature of the previous day°C3, 4, 7N: number of days in a month—3, 4N(d): number of dry days in a month—3, 4N(w): number of wet days in a month—3, 4bT: scaling factor—3, 4k0: dry/wet days separation option—3, 4, 6Ak0,k: 3×3 matrix function of the lag-0 serial- and cross-correlation coefficients of the residuals on dry (k= 0) or wet (k= 1) days—3, 4, 6Bk0,k: 3×3 matrix function of the lag-1 serial- and cross-correlation coefficients of the residuals on dry (k= 0) or wet (k= 1) days—3, 4, 6χ(d-1)k0,k(j): standardized residual of maximum (j= 1) and minimum (j= 2) air temperatures and global solar radiation (j= 3) on dry (k= 0) or wet (k= 1) days for the previous day—3, 4K0: daily dew point air temperature correction factor°C2a, b, c, d: empirical parameters of model Hubbard for daily dew point air temperature-, -, -, °C2A, B, C, D, E, F, G: empirical parameters of model of Kimball et al. for daily dew point air temperature-, -, -, -, -, -, °C2EF: evaporative demand—2A1,B1,C1,D1,E1: empirical parameters of model Linacre 1 for daily dew point air temperaturem-1, -, -, -, °C2A2,B2,C2,D2: empirical parameters of model Linacre 2 for daily dew point air temperature-, °C-1, -, °C2hrdv: hour of the day for maximum air temperature to occurh7Tmin(d+1): minimum air temperature of the next day°C7sr(d+1): time of sunrise of the next dayh7ss(d+1): time of sunset of the next dayh7T(ss(d-1)): air temperature at sunset of the previous day°C7aslp: slope coefficient—7LSH: hour of maximum solar heighth7p: delay of the maximum air temperatureh7Tk: air temperature increment°C7TC: nocturnal time coefficienth7k: shift factor—7AP, BP, CP: empirical parameters of model of Porter et al. for hourly air temperatureh, h,-7AS, BS, CS, DS, ES: empirical parameters of model Stöckle for hourly air temperature-, -, -, -, -7Td(d+1): dew point air temperature of the next day°C1Td(max): maximum dew point air temperature°C1


## 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 forAirTemperature. 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 implementsStrategies, 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 patternsComposite 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 ofAirTemperature 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.



---

*Source: 812789-2010-05-05.xml*