Agronomy Journal Journal of Natural Resources and Life Sciences Education
HOME HELP FEEDBACK SUBSCRIPTIONS ARCHIVE SEARCH TABLE OF CONTENTS
QUICK SEARCH:   [advanced]


     

Published online 5 January 2006
Published in Agron J 98:220-228 (2006)
DOI: 10.2134/agronj2005.0109
© 2006 American Society of Agronomy
677 S. Segoe Rd., Madison, WI 53711 USA
This Article
Right arrow Abstract Freely available
Right arrow Figures Only
Right arrow Full Text (PDF) Free
Right arrow Alert me when this article is cited
Right arrow Alert me if a correction is posted
Services
Right arrow Similar articles in this journal
Right arrow Similar articles in ISI Web of Science
Right arrow Alert me to new issues of the journal
Right arrow Download to citation manager
Right arrow reprints & permissions
Citing Articles
Right arrow Citing Articles via HighWire
Right arrow Citing Articles via ISI Web of Science (1)
Right arrow Citing Articles via Google Scholar
Google Scholar
Right arrow Articles by Bauerle, W. L.
Right arrow Articles by Anantharamu, S.
Right arrow Search for Related Content
PubMed
Right arrow Articles by Bauerle, W. L.
Right arrow Articles by Anantharamu, S.
Agricola
Right arrow Articles by Bauerle, W. L.
Right arrow Articles by Anantharamu, S.
Related Collections
Right arrow Evapotranspiration Models
Right arrow Plant Analysis

Computers in Agriculture

Adaptation of the Biological Simulation Model MAESTRA for Use in a Generic User Interface

William L. Bauerlea,*, Dennis J. Timlinb, Yakov A. Pachepskyc and Shruthi Anantharamud

a Dep. of Hortic
d Dep. of Electrical and Computer Eng., Clemson Univ., Clemson, SC 29634
b USDA-ARS, Crops Syst. and Global Change Lab., Beltsville, MD 20705
c USDA-ARS, Environ. Microbial Safety Lab., Beltsville, MD 20705

* Corresponding author (bauerle{at}clemson.edu)

Received for publication April 12, 2005.

   ABSTRACT
TOP
 ABSTRACT
INTRODUCTION
 GUICS AND ITS ADAPTATION
 CONCLUSIONS
 REFERENCES
 
Application of process-based models beyond the research community has been limited, in part because they do not operate in an intuitive graphical user-friendly environment. This article describes the procedure of adapting a spatially explicit biological-process model, MAESTRA (Multi-Array Evaporation Stand Tree Radiation A), to run in a standard graphical user interface (GUI). The methods used to adapt the MAESTRA model are generally applicable to other individual tree process-based models and, therefore, should simplify other coupling attempts. The three primary changes to MAESTRA were the placement of the MAESTRA code inside a Microsoft Windows API (application programming interface) function called WINMAIN, rearrangement of the input file structure to fit the hierarchical file structure used by the Graphical User Interface for Crop Simulations (GUICS), and the addition of iteration counters to read array-based data read for each array within the MAESTRA input files. The procedure of adapting MAESTRA's input structure and interface design should allow other forest stand process-based models to work within GUICS.

Abbreviations: API, application programming interface • GUI, graphical user interface • GUICS, Graphical User Interface for Crop Simulations


   INTRODUCTION
TOP
 ABSTRACT
 INTRODUCTION
GUICS AND ITS ADAPTATION
 CONCLUSIONS
 REFERENCES
 
PHYSIOLOGICAL or process-based forest models describe explicit biophysical and biochemical mechanisms with predictive algorithms. Within the last two decades, hundreds of ecological and agricultural simulation models have been developed in an attempt to predict terrestrial ecosystem response to climate change (see reviews by Reynolds et al., 1996; Reddy et al., 1997; Goudriaan et al., 1999; Constable and Friend, 2000; Johnsen et al., 2001). Recently, substantial effort was made on developing mechanistic forest ecosystem models because trees are major components of the terrestrial ecosystem C pool (Dixon et al., 1994). Mechanistic or process-based approaches are powerful tools that can be used to provide insights into forest dynamics. However, they often are complex and lack a user-friendly GUI inside a windowing environment. This prevents most models from being used by more than a handful of researchers, let alone beyond the research community.

The input data for a mechanistic tree model usually includes tree-specific physiological and structural parameters, weather data, and indirect soil water content (moisture status based on soil water-holding capacity and precipitation) as inputs to calculate primary productivity over the course of one or several growing seasons. Despite the common information input, the models vary considerably in framework and form, each representing the facets of the particular system considered crucial for modeling system behavior. The problem of data compilation is compounded by the fact that the complex nature and lack of a standardized Windows-based user interface currently precludes process-based models from being commonly used in the forest decision-making process. Before any model can become widely used, it must not have only clear documentation and a widely understood program language, but also possess a standardized input structure that can easily couple to a GUI. The use of GUICS as a generic user interface is the key next step in knowledge dissemination because it provides end users a simplified tool to operate complex forest ecophysiological models.

As populations infringe on areas that were once designated specifically for forest growth, it will become increasingly critical for forest managers to quantify projected impact on existing and future stand management and other associated changes in climate. Forest management, therefore, will soon require using model predictions for critical decisions regarding protection, treatment, and utilization of forest resources (Mäkelä et al., 2000). The potential application of process-based models, however, is currently limited by operational implementation (Acock et al., 1999; Mäkelä et al., 2000; Johnsen et al., 2001). Recently, Ditzer et al. (2000) exemplified the need to visualize forest process model output when they were successful in using geographic information systems to aid forest management decision-making. The mechanistic nature of process models linked to a GUI lends to this precise task because the process-based structure allows them to simulate responses that the system has never encountered and visually present the outcome. Moreover, from an educational and research perspective, process-based models provide insights into the underlying biological response to ecosystem perturbations, a key tool for deciphering forest and ecosystem response.

For the purpose of the application of process-based sustainable forest and tree nursery management analysis, we have developed a GUI that standardizes model/interface coupling and simplifies end user operation. The original objective of this work was to couple a forest process-based model (MAESTRA) (Medlyn et al., 1999) to a generic GUI. In so doing, we encountered a number of challenges. We describe the difficulties, as well as our solutions, to hopefully simplify other GUI/forest process-based model coupling attempts.


   GUICS AND ITS ADAPTATION
TOP
 ABSTRACT
 INTRODUCTION
 GUICS AND ITS ADAPTATION
CONCLUSIONS
 REFERENCES
 
The GUICS Interface
A GUICS that is user friendly, capable of running numerous crop simulators, and available as freeware was described in Acock et al. (1999). Briefly, GUICS is a WIMP (Windows, Icons, Menus, and Pointers) interface (Martin and Eastman, 1996), where the design is user centered (Microsoft Press, 1995). To enhance usability, the design's interface incorporates six features: consistency, directness, feedback, forgiveness, simplicity, and user in control. Detailed descriptions of these features can be found in Acock et al. (1999).

Although other crop model interfaces have been developed and are described in the literature (e.g., Van Evert and Campbell, 1994; Testezlaf et al., 1996; Bannayan and Crout, 1999), they are either crop specific or built for a specific suite of crop simulators. The GUICS is an attempt to standardize a GUI across various crop simulators, each of which may be crop specific but still present within an ecosystem (i.e., a single farming operation; see Acock et al., 1999). The interface was designed to minimize coding changes in the simulation model. Simulation models read data and output results; therefore, the connection with the user interface is via these input/output files. GUICS acts as an intermediary between the user and model. The simulation model provides data files to GUICS, and GUICS presents the data to users via a combo box or dialog box, a combination of a text box and a list box where the user can type a value or choose one from a list. Required changes to the model source code, therefore, are normally limited to file input and output routines.

Users of crop or biological simulation models are often interested in comparing the effects of competing management decisions or contrasting environment on plant performance. For example, if the summer is wet and cool, how will it affect the harvest date as compared with a hot, warm summer? This requires that a user run a simulation a number of times with different input files. If the basic component of the model is a tree or cropped plant, i.e., corn (Zea mays L.), soybean [Glycine max (L.) Merr.], etc., each simulation represents a specific state in which the tree or plant would grow. Weather, soil, plant variety, management such as irrigation, initial conditions including row spacing, and planting date define this state. GUICS is designed so that input files, representing the possibilities of different states, can be easily manipulated and selected. Each arrangement of files defines a scenario that, after execution of the model, would provide a user with an estimate of how a crop would respond to that particular state of the system.

GUICS allows a user to build variations on a scenario. The user selects two or more files of the same category of data (soil, weather, etc.) that represent the different states of the system where a comparison is desired. To build scenarios efficiently, the input data files must be grouped into those that are specific to a particular scenario or simulation or those that are common to more than one scenario. For example, an initialization file that contains row spacing and planting date would be specific to a simulation for a particular field and crop (a scenario). A weather file, on the other hand, could be used for a range of scenarios for the same field and crop. Different variety files could be used for the same weather and initialization file to create several scenarios. If initialization and variety data are mixed into one file, then it would be difficult to simulate results for several varieties on one field without having to create multiple copies of the same file, each with a slightly different value of one or more variables.

It may be necessary to recode a model to work with GUICS so that its input files are allowed to have a variable file name and are arranged in nonoverlapping categories. Many models, originally written for DOS operating systems that include MAESTRA, use the same input file names (the file names are hard-coded) and vary the folder or directory names for different simulations. Although this simplified the input in a DOS environment (via the use of master input files), this is a disadvantage in a user interface where the necessity to easily manipulate files requires a structured file system. A convenient way to manage files for a user interface is in a hierarchical file structure. With a hierarchical arrangement, common files such as weather or physiology parameter files are stored in separate folders and can have names appropriate to the source or use of the data. The folders, in turn, will correspond to different categories of input data. The redundant data among the input files can be removed and the related information encapsulated in the input files to increase efficiency. A GUI, moreover, simplifies input of file names since a user can select a file from a list drawn from the same folder and having a common category and file extension.

A programmer must carry out several tasks to make an existing crop simulator capable of working with GUICS (Acock et al., 1998). The first task is to reorganize and document the input and output datasets (or datafiles). This places the structures of the files into a known format and provides information to GUICS on how to read the files. The documentation is available to GUICS as script files, which provide information on titles for dialog boxes and formats for reading and writing data. The simulator and GUICS also need to maintain some kind of synchronization to update simulation status to the interface and user and handle errors. This messaging is implemented by adding standard code to the simulator to send messages to GUICS concerning the model's progress (i.e., calendar date) during the course of the simulation and by notifying GUICS when the simulator ends.

Script files are used by GUICS to describe the structure of the input datasets, specific to the simulator, and describe the variables present in the model's input and output files. Each folder has an associated script file (named <component-name>.sct) to document the data contained in the files in that folder. The script file contains three lines for every item of data read by the model (Table 1). These lines include an iteration number (to number the sequence of the variable and landmark when editing), a title for the variable in the dialog box, and a format string to describe how GUICS should read the variable and write it to a file if the user changes the input file (Table 1). The format strings allow for date, character, and numeric data; tabulation of data in row–column format; and presentation of data in combo or drop-down boxes. A user can select from a number of items in a combo or drop-down box. Special script files are also written to present output data in tabular and graphic forms. Additional related files with the name <component-name>.def are default data files that can be used as templates by the end user to create new input files in GUICS.


View this table:
[in this window]
[in a new window]
  		Table 1. Example of a script that describes to the Graphical User Interface for Crop Simulators (GUICS) the format of weather data and how to read the weather data file.

 
Adapting GUICS
When GUICS was developed, the input files used in over 20 other simulation models were evaluated (Acock et al., 1998). In spite of this, new formatting types were found in both MAESTRA and other models such as Simpotato (Hodges et al., 1992). One of them was the use of an "=" symbol to separate a parameter from a description. A new script grammar had to be added to GUICS to handle this case.

The MAESTRA Model and Its Adaptation
A detailed description of MAESTRA is beyond the scope of this article; interested readers are referred to Wang and Jarvis (1990a, 1990b), Bauerle et al. (2002, 2004a), and Medlyn (2004). Briefly, MAESTRA, a spatially explicit biological-process model originally developed for tree plantations-MAESTRO (Multi-Array Evaporation Stand Tree Radiation O; Wang and Jarvis, 1990b), and recently updated and renamed MAESTRA (Medlyn et al., 1999), simulates gross and net photosynthesis, light absorption, stomatal conductance, transpiration, canopy temperature, and respiration in complex forest canopies using detailed information on leaf area, leaf distribution, physiological parameters, light interception, and stand structural characteristics. Bauerle et al. (2002) recently demonstrated that the transpiration of deciduous trees could be estimated with MAESTRA. For the purposes of water and C management, MAESTRA is a valuable tool to assess intracrown and intracanopy response to interacting environmental variables such as CO2, water, and light (Bauerle et al., 2004a). Various MAESTRO and MAESTRA versions exist; however, our version was originally downloaded from the official MAESTRA website (www.maestra.unsw.edu.au/; verified 26 Oct. 2005) and has been modified by Bauerle et al. (unpublished data, 2005) to include leaf temperature response functions (Bernacchi et al., 2001, 2002, 2003), physical and hormonal drought response functions (Bauerle et al., 2002, 2004b), and deciduous tree light transfer (Bauerle et al., 2004a). Overall, MAESTRA is a forest ecosystem model recently applied in several studies including Medlyn (1998), Livingston et al. (1998), Luo et al. (2001), and Binkley et al. (2002).

Adapting MAESTRA to GUICS
MAESTRA is called from GUICS as an executable (EXE) although it could be called as a dynamic link library (DLL). This ensures the independence of the simulator from GUICS in terms of coding. The EXE or DLL, when called from GUICS, needs to be directed to where GUICS resides in memory. This provides for the exchange of messages between MAESTRA and GUICS since they have access to each other's memory space. This is implemented by placing the MAESTRA code inside a Microsoft Windows API function called WINMAIN. The specific routine used, however, depends on the compiler (which does not have to be the same as that used by GUICS). Since MAESTRA becomes a Microsoft Windows function, the main program becomes a SUBROUTINE rather than a MAIN program and can be added as a new model using a dialog box in GUICS. When this was implemented in MAESTRA, the code had to be cleaned up to remove or recode all FORTRAN STOP and EXIT routines that would have allowed the simulator to end and leave memory without notifying GUICS. All subroutines were checked to make sure that control was always passed back to the calling routine when a subroutine was finished.

Some programs can write messages or other text to the monitor or console to show simulation progress or errors as the model runs. This is possible in GUICS, but all screen output must be handled by GUICS. For example, write (FORTRAN) statements to console must be deleted from the source code or redirected to a file. All console write statements in MAESTRA were deleted, and error messages were directed to an error file. Progress through the simulation is updated by having MAESTRA send the current day to GUICS, which then displays the date in its window. The MAESTRA code had to be altered to calculate the current date of simulation rather than days past the simulation start date. When the simulation ends, a message is sent to GUICS by MAESTRA to allow GUICS to close the window for the simulator. This messaging is implemented using WINDOWS API functions such as SENDMESSAGE.

The most significant change to MAESTRA was in the structure of the input files that had to be altered to fit the hierarchical file structure of GUICS. The structures of the five input files of this particular forest simulator were modified without affecting the data contained in the files. Each input file corresponds to a GUICS "dataset." The dataset consists of three files. The header file, <dataset>.hdr, contains the logical name of the dataset. The icon file, <dataset>.ico, contains the datasets' icon. The datasets' data file, <dataset>.xxx, contains the datasets' data. The extension (.xxx) is a function of the category of the data and varies with the types of datasets. For example, weather files have the extension <.met>.

The method by which MAESTRA reads input data was changed to fit the requirements of GUICS. The input file names were originally hard-coded in MAESTRA to minimize user intervention in a DOS environment. Projects were run in different directories to separate them. MAESTRA was therefore modified to use variables for the file names rather than hard-code them. Further modifications allowed MAESTRA to read the input and output file names from the run.dat file and read from or write to them.

Another modification to the MAESTRA input files was in the area of reading array-based data. Array-based data are in rows, and the number of lines or rows read is controlled by a counter that is read first. For example, to read data from a soil file where there can be a variable number of depths, an iteration counter to define the number of soil depths will be read first, and then the number of rows of data to be read are defined by that counter. Because GUICS uses C-type pointers for iteration counter variables, only one iteration counter can be read for each array. MAESTRA was originally designed to read an iteration counter and reuse it for later rows of data. Therefore, additional iteration counters had to be added to the MAESTRA input files.

MAESTRA required and still requires five data input files to run simulations. The files and brief primary function are as follows: confile.dat controls model run time and execution frequency, str.dat defines canopy structure components, phy.dat characterizes the physiological input parameters, met.dat consists of the weather data, and trees.dat details the plot, crown dimension, and positions per tree. Figure 1 further illustrates the different categories of MAESTRA data input and how that is now categorized in GUICS. Figure 2 shows a dialog box with input data that are ready for editing by a user. Readers are referred to the website www.maestra.unsw.edu.au/ for a more in-depth description of each file and its structure and input variables.



View larger version (94K):
[in this window]
[in a new window]
  		Fig. 1. The different categories of data in the MAESTRA model as used in the Graphical User Interface for Crop Simulators (GUICS). Each tab points to a different dialog and different file.

 


View larger version (81K):
[in this window]
[in a new window]
  		Fig. 2. A dialog box illustrating the data format for data within the TREE DATA category (e.g., trees.dat).

 
The changes in the structure of the input files were concomitant with a change in the focus of MAESTRA from a multitree to single-tree simulation. MAESTRA defines the growth of a single tree, but originally, simulations ran on an array of trees. The output corresponded to this array of trees. The MAESTRA model was modified to simulate one tree at a time in an array of trees (Fig. 3 ). Different trees could be simulated and/or compared by using GUICS to vary a scenario and hence vary files having different tree parameters (Fig. 4 ). The MAESTRA code was then altered to output simulation results for one tree to a single file rather than many trees to a single file where the output values were identical to the original unlinked MAESTRA version on an individual-tree basis. Once a dataset is assembled and computed, each simulated tree parameter could be selected for graphical illustration (Fig. 5 ). Graphical presentation of the results of several tree simulations over the course of a season (Fig. 6 ) is handled by GUICS by selecting the results of two or more scenarios. Originally, all files presided in the same folder with the executable file. Hence, data files had to be changed individually and had to completely overwrite the pre-existing file. GUICS required each data file plus the executable file to preside in its own individual folder in GUICS, and thus, changes were made accordingly. The new split folder method allowed us to have multiple data files in each category, e.g., <tree number>.con files for configuration data, each of which could be modified through the GUICS interface. The data file was given an extension that corresponded with the data type, thus permitting an overarching file called run.dat to have all five input file names dynamically input into run.dat using the GUICS. Before this configuration, the file input was static, and modification to any one of the five input files required a complete file overwrite. Another change to the overall MAESTRA structure required us to reduce the amount of concurrent tree simulations from several to one. However, multiple runs of different trees resulted in the same per-tree output. Lastly, the total number of trees present in the data had to be specified in trees.dat for data-accounting purposes, i.e., to edit tree data in table format within a GUIC dataset window (please see Row 11 in Fig. 2 for an illustration of the parameter addition).



View larger version (54K):
[in this window]
[in a new window]
  		Fig. 3. A scenario dialog box that illustrates the tree, creation date, and status of the scenario.

 


View larger version (101K):
[in this window]
[in a new window]
  		Fig. 4. The input dataset selection window for various datasets that reside in individual folders.

 


View larger version (80K):
[in this window]
[in a new window]
  		Fig. 5. Variable selection dialog box for graphical and/or tabular presentation.

 


View larger version (98K):
[in this window]
[in a new window]
  		Fig. 6. The graphical display presentation of four output variables (gross photosynthesis, net photosynthesis, foliar respiration, and transpiration) for two different trees and their respective simulations.

 
The Process of Building and Executing a MAESTRA Scenario in GUICS
A scenario contains all the components of a simulation. Scenarios are organized into projects based on common features of the scenarios. A user creates a scenario by choosing a name for the scenario, adding comments to document the simulation, and selecting appropriate input files—one from each category of data. GUICS writes the input file names to a file with the scenario name and the extension ".run" and saves it to a subfolder in the projects folder. This subfolder has the same name as the scenario name. Thus, all input and output related to a scenario are encapsulated into a single folder. The input only includes file names; the original data still reside in the simulation model's directory. The output files, however, are kept in the projects' folder. When the user chooses to run the simulation, GUICS copies the <scenario>.run file to a file called run.dat and then invokes the simulator. The simulator reads the run.dat file, assigns the input file strings to the appropriate variables, and opens the input files. The output files are also read from the run.dat file, assigned to appropriate variables, and opened for output. GUICS provides for four kinds of output files, but not all have to be created by a model. These include a graphics file, table file, summary file, and report file. These will be described in greater detail with respect to integration with MAESTRA. Complete details of GUICS are provided in Acock et al. (1999), with directions to the accompanying GUICS (Ver. 2.4) user manual (Acock et al., 1998) currently available at www.ars.usda.gov/Services/docs.htm?docid=6352 (verified 26 Oct. 2005).

The output files of the simulator were modified to display the results in graphical form using GUICS. Output was also directed to a subfolder in the project's folder. The file names and locations are read from the run.dat file. A script file is used to inform GUICS how to read the output file and what labels to use for the data. To display the results in graphical form, it was necessary to write a script file similar to the example in Table 1, and Table 2 illustrates a sample of the MAESTRA daily output before display in graphical form. An alteration in the MAESTRA code was necessary to produce the modified output files. This included formatting and writing out specific variables as well as outputting results from a single tree only. The method was followed to get the results in the form of tables, summaries, and reports. Various scenarios on an individual-tree basis could then be assembled and computed (Fig. 3).


View this table:
[in this window]
[in a new window]
  		Table 2. A sample of the MAESTRA daily output.

 
To view the output, the MAESTRA model had to write the following files:

Illustrations of the graphics output are depicted in Fig. 6, whereas Fig. 7A , 7B, and 7C illustrate a summary file, example table that illustrates the average of an output variable (e.g., daily transpiration) calculated for the number of days of the simulation, and report resulting from the output files, respectively. The simulator produced only the necessary four files and accomplished this by having MAESTRA read the output file names along with the path from a file named run.dat. MAESTRA then created those files and sent the output to them.



View larger version (65K):
[in this window]
[in a new window]
  		Fig. 7. (A) A "summary" file that contains compact information about simulation results, (B) a "table" file that contains the numerical results of simulations, and (C) a "report" file that contains a detailed output needed for analysis of a particular simulation.

 

   CONCLUSIONS
TOP
 ABSTRACT
 INTRODUCTION
 GUICS AND ITS ADAPTATION
 CONCLUSIONS
REFERENCES
 
To scale up individual tree simulations to forest ecosystems, multiple tree simulations can be run and compared to permit whole-forest and nursery assessment (e.g., Fig. 6), and seasonal averages can quickly be compared (e.g., Fig. 7B). However, additional work is required to expand MAESTRA to include other decision support and risk assessment beyond canopy growth processes (e.g., root respiration, nutrient stresses, and insect or disease perturbations). The procedure of adapting MAESTRA's input structure and interface design should allow other forest stand process-based models to work within GUICS.

In the context of climate change, modelers are confronted with complex models that are not integrated into a common GUI. The consequence is that model inputs and outputs are not managed by an integrated software system. Similar to the extension of mechanistic models with the group method of data handling (Reddy and Pachepsky, 2000), the results show that the operation of MAESTRA within GUICS can be used to extend the usability and scope of computationally intensive mechanistic biological simulation models. Specific to MAESTRA, there are several advantages of coupling MAESTRA with a GUI, including visual comparison of tree simulation results; less complicated input data, which makes it straightforward for the end user to use the model; and shorter simulation time. This is important for climate-change studies and because process-based models project the impact of climate change and allow investigating the response of a system outside the range of historical data. In addition, it integrates the plant–soil–atmosphere–management interaction into a user-friendly Windows environment.

A flexible system that helps visual interpretation of spatially explicit simulation data within a generic GUI is presented. This system will enable others to modify their particular model structure so that it can interface GUICS. The integration of a simulation model into a user interface is greatly simplified when the data for the simulation model are arranged in a hierarchical manner (Cox, 1996). This arrangement facilitates the segregation of data into groups having common characteristics. The objective is to provide a means to arrange the input data into variations of weather, physiological parameters, soil, or management to easily compare different simulations. The goal is also to provide an intuitive user interface to manipulate and organize the input data needed for a simulation model. The user-friendly environment for process-based models will be an effective way to increase their application beyond the research community. However, the simulation quality, validity, and performance of any model, whether it is run within a GUI or not, depends on the user.


   ACKNOWLEDGMENTS
 
We acknowledge the assistance of Geetha Reddy in making modifications to GUICS. We also thank Dr. Basil Acock, Dr. James Ascough III, and Dr. Elaine Poulin for helpful comments on earlier drafts of the manuscript. This work was funded by the South Carolina Experiment Station.


   REFERENCES
TOP
 ABSTRACT
 INTRODUCTION
 GUICS AND ITS ADAPTATION
 CONCLUSIONS
 REFERENCES
 




This article has been cited by other articles:


Home page
 J Exp BotHome page
W. L. Bauerle, J. D. Bowden, and G. G. Wang
The influence of temperature on within-canopy acclimation and variation in leaf photosynthesis: spatial acclimation to microclimate gradients among climatically divergent Acer rubrum L. genotypes
J. Exp. Bot., September 4, 2007; (2007) erm177v1.
[Abstract] [Full Text] [PDF]

This Article
Right arrow Abstract Freely available
Right arrow Figures Only
Right arrow Full Text (PDF) Free
Right arrow Alert me when this article is cited
Right arrow Alert me if a correction is posted
Services
Right arrow Similar articles in this journal
Right arrow Similar articles in ISI Web of Science
Right arrow Alert me to new issues of the journal
Right arrow Download to citation manager
Right arrow reprints & permissions
Citing Articles
Right arrow Citing Articles via HighWire
Right arrow Citing Articles via ISI Web of Science (1)
Right arrow Citing Articles via Google Scholar
Google Scholar
Right arrow Articles by Bauerle, W. L.
Right arrow Articles by Anantharamu, S.
Right arrow Search for Related Content
PubMed
Right arrow Articles by Bauerle, W. L.
Right arrow Articles by Anantharamu, S.
Agricola
Right arrow Articles by Bauerle, W. L.
Right arrow Articles by Anantharamu, S.
Related Collections
Right arrow Evapotranspiration Models
Right arrow Plant Analysis

HOME HELP FEEDBACK SUBSCRIPTIONS ARCHIVE SEARCH TABLE OF CONTENTS
The SCI Journals Crop Science Vadose Zone Journal
Journal of Natural Resources
and Life Sciences Education		 Soil Science Society of America Journal
Journal of Plant Registrations Journal of
Environmental Quality		 The Plant Genome