A decision support system for above-ground herb and shrub growth, forage consumption and hydrologic processes
PHYGROW, short for phytomass growth model, is a daily time step computation engine that models above ground herb and shrub growth, forage consumption, and hydrologic processes. It is capable of modeling the growth dynamics of many plant species competing for limited resources while modeling grazing by herbivores in competition for forage resources.
Phygrow is a point-based, daily time step, algorithmic or computation engine that models above-ground plant growth, forage consumption and hydrological processes. The model was first coded in 1990 and has undergone many enhancements since that time. The model’s original computation algorithms are a mixture of formulas adapted from other plant growth models — CREAMS, GLEAMS, EPIC, WEPP, SPUR, CENTURY, ERHYM-II — as well as the biological relationship from grass tiller level research and dietary selection conducted at Texas A&M University.
The model is capable of stimulating the growth of multiple species of plants subject to selective grazing by multiple animals on soil with multiple layers for indefinite periods of time. Phygrow is designed to be integrated with a wide variety of weather databases, vegetation databases, and stocking rule databases. It provides output for a wide variety of data sources and formats including all relational databases, NetCDF file formats, commas-separated and tab-delimited file formats, and linkages to other models and the internet using Python, Perl, and Java web applications.
Phygrow requires 4 primary data sources to run: soil, weather, grazers, and plant data. Consequently, due to the lack of available sources for plant parameters, the largest repository for such data is the database link to PHYGROW. For soils, the system was primarily designed to work with data from SSURGO or STATSGO, however, it can use soil data from any source, provided the attributes needed to run the model are supplied. Grazing information is usually collected in the field by survey crews and entered directly into the model’s parameter database. Weather data can be pulled from numerous sources. We primarily use products from NOAA, however, we can use data collected from weather stations and other various sources.
Final data input to the PHYGROW model is required to be in the form of a comma-separated values (CSV) ascii file with a defined data format. However, many data import interfaces have been written for the PHYGROW computational engine that allows for source data to be input via an interactive web page (eg. PhyWeb 2.0) or imported from existing database systems or spreadsheets.
The model has a unique capability to be started and stopped at any point in the computational process to allow full integration with data acquisition systems, automation systems, and/or other models. The PHYGROW model engine is written in the C++ programming language and uses an object-oriented design, thus allowing high efficiency in the incorporation of new scientific relationships when necessary. Because of the start-restart features of the model, simulations can be integrated at various spatial scales in terms of explicit areas across a landscape, or in a virtual landscape representing multiple plant communities and soil combinations via a spatially explicit multiple run mode. The PHYGROW model can be run in an automated environment across multiple platforms most Linux environments and as a standalone application in Windows 10 and later.
The primary system located at CNRIT utilizes a distributive computing environment. This allows streaming of data from many weather and soil database sources thus allowing near real-time computation of plant growth. At the other end of the equation, other entities around the world can write applications that access the output from PHYGROW, or the output can be sent to other distributed computing systems around the world.
PHYGROW does not require the use of commercial or customized data storage systems. However, the model can use both commercial and customized data storage systems. All the tools and middleware for the automated systems are developed with non-proprietary software. The way the data is acquired, stored and output is dictated by the needs of the user. That is, what kind of weather data, the number of plant community/soils/grazer/weather combinations to be modeled, the frequency of reporting, the required linkages to other applications (e.g. actuarial, insurance companies, RMA) and the nature of the output (graphical, text or both on the web, ftp or other) will determine the design and functionality of the automation process.
How to Get and Use Phygrow
PLEASE NOTE: if you will be running Phygrow on a Microsoft Windows computer to test your model runs and then you also run the same model on a UNIX machine, you will see slight variations in the model output. This is due to the different ways in which floating point arithmetic is handled in Windows C++ compilers versus UNIX C++ compilers. It amounts to several decimals places deep rounding error, but the errors can compound to show visibly differing results for the same model. Phygrow has been developed and tuned against the UNIX results because this version does not truncate the floating point numbers arbitrarily and therefore produces the most accurate numbers.