ASABE Logo

Article Request Page ASABE Journal Article

WebStart WEPS: WEPS with Remote Data Access and Cloud-Computing Functionality

Larry E. Wagner1,*, Mark E. Haas1, Fred A. Fox1


Published in Journal of the ASABE 65(2): 427-436 (doi: 10.13031/ja.14773). 2022 American Society of Agricultural and Biological Engineers.


1 USDA-ARS Rangeland Resources and Systems Research Unit, Fort Collins, Colorado, USA.

* Correspondence: larry.wagner@ars.usda.gov, wagner@ksu.edu

The authors have paid for open access for this article. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License https://creative commons.org/licenses/by-nc-nd/4.0/

Submitted for review on 6 August 2021 as manuscript number NRES 14773; approved for publication as a Research Article and as part of the Soil Erosion Research Symposium Collection by the Natural Resources & Environmental Systems Community of ASABE on 19 January 2022.

Mention of company or trade names is for description only and does not imply endorsement by the USDA. The USDA is an equal opportunity provider and employer.

Highlights

Abstract. The Wind Erosion Prediction System (WEPS) is a physical process-based wind erosion model developed by the USDA Agricultural Research Service (USDA-ARS). WEPS simulates daily climate and management-driven changes to the surface, vegetation, and soil. It estimates erosion losses when surface conditions and wind speeds are sufficient for soil movement. WEPS was released in 2010 to the USDA Natural Resources Conservation Service (USDA-NRCS) for assisting land managers in controlling wind erosion, establishing field-level plans for soil conservation, and determining wind erosion susceptibility as a part of national conservation programs to conserve the soil resource. The WEPS interface allows easy user access to national-scale input data. Four primary inputs are required to set up and execute a WEPS run: (1) field dimensions; (2) field location, which automatically determines applicable local climate data; (3) a representative soil; and (4) time series of management practices. These inputs require access to a significant amount of data, which are typically stored locally; however, maintaining these data on every computer running WEPS and keeping them current were problematic for the NRCS. To address these concerns, remote access functionality was incorporated into WEPS to deliver climate and wind data, as well as soil, operation, crop/residue, and management (a date-sequenced list of management operations) records. In addition, WebStart WEPS also features the option of running WEPS components remotely “in the cloud” as web services. The Java WebStart framework provides a simplified delivery mechanism to users’ computers and offers automatic updating capability.

Keywords. Cloud services, CSIP, Erosion, Java WebStart, Modeling, WEPS, Wind erosion.

The Wind Erosion Prediction System (WEPS) (Wagner, 2013) is a daily time step, process-based wind erosion model developed by the USDA Agricultural Research Service (USDA-ARS, 2020). WEPS simulates climate and management-driven daily changes to the surface, vegetation, and soil. It estimates erosion losses when the surface friction velocity exceeds the computed surface threshold friction velocity. In 2010, WEPS was released to the USDA Natural Resources Conservation Service (USDA-NRCS, 2010) and has since been periodically updated. WEPS is now the USDA-NRCS preferred wind erosion model for: (1) assisting land managers in controlling wind erosion, (2) establishing field-level plans to conserve the soil, and (3) determining wind erosion susceptibility as a part of national conservation programs to conserve the soil resource. WEPS greatest attribute is its functionality as a “what-if” tool to evaluate management scenarios for developing and evaluating alternative wind erosion control practices.

WEPS currently consists of a modular coded Fortran science model and a multi-platform capable, Java-based user interface. The interface allows easy access to national-scale weather and soil data as well as crop/residue and operation records representing the most commonly grown crops and operations used in the U.S. Only four primary inputs are required to set up and execute a WEPS run: (1) field dimensions (size/shape/orientation), (2) field location (selected field lat/long coordinates automatically determine local climate and wind data to use in the simulation), (3) representative soil characteristics for the field, and (4) a date-ordered list of management practices describing the cropping rotation sequence.

However, these inputs require access to a significant amount of data typically provided in locally stored files and records. Storing these data locally on every field office computer nationally and keeping them current presents numerous challenges to the NRCS (e.g., large storage requirements as well as difficulty with managing data updates). To address these concerns, we provided remote access to climate/wind and NRCS soil data, as well as the operation, crop/residue, and management records through the WebStart WEPS interface. WebStart WEPS allows remote access to the necessary data and enables the option of running model components in the cloud. This reduces both the computational and storage requirements of client (user) computers if the user has adequate internet access to connect to the remote services.

We also employed the Java WebStart framework to provide a simplified delivery mechanism to user computers that also offers automatic updating capability and the ability to access (start) WEPS from a web-based URL link. Thus, we kept the full functionality of the current desktop interface, retained the current interface look and feel, and leveraged the current code, all without rewriting the interface as a native web browser application. To better distinguish this release of WEPS from previous releases, we also used WebStart as a prefix to WEPS.

Background

In 2015, the NRCS National Agronomist asked that we provide the following major features in a future update of WEPS:

  1. Remote access capability to obtain the data necessary for WEPS simulations.
  2. The ability to execute WEPS simulations remotely, including generation of daily weather and wind parameters for WEPS simulations.
  3. The ability to execute, or start up, WEPS from an internet URL web link.

    <!-- CSIP Soils configuration parameters -->

    <parameter> <!-- CSIP soils catalog endpoint -->

    <name>CD-WS-csip-soils-params-endpoint</name>

    <value> https://csip.engr.colostate.edu:9083/csip-soils/d/wwesoilparams/1.1</value>

    <access>write</access>

    </parameter>

    <parameter> <!-- CSIP soils data endpoint -->

    <name>CD-WS-csip-soils-data-endpoint</name>

    <value> https://csip.engr.colostate.edu:9083/csip-soils/d/wepssoilinput/2.0</value>

    <access>write</access>

    </parameter>

    <!-- CSIP Soil selection polygon size -->

    <parameter> <!-- CSIP Soil selection polygon (value stored in acres right now) -->

    <name>CD-WS-csip-Soil-polygonSize</name>

    <value>160.0</value>

    <access>write</access>

    </parameter>

Figure 1. Excerpt of WEPS configuration file contents containing CSIP Soil URL endpoints and configuration options. This snippet of the XML-formatted configuration file information is presented to show how the model represents some of the remote service parameters.

To address the first two NRCS requests, we used Colorado State University’s Cloud Services Integration Platform (CSIP) (David et al., 2016), a “model-as-a-service” platform tailored for the delivery of model and data services in the environmental domain (David et al., 2014). CSIP was designed to address model re-use, deployment, distribution, data provisioning, and maintenance and scalability issues, as well as eliminating programming language constraints and separating model user interface (UI) and model engine coding. CSIP is based on a RESTful server-client application programming interface (API), JavaScript Object Notation (JSON), and Java Architecture for XML Binding (JAXB). The CSIP services deployed using Kubernetes (Kubernetes, 2021) can be implemented in Java, Python, R, or mapped to existing external executables.

The data services provided by CSIP for WebStart WEPS consist of soil and Conservation Resources Land Management Operations Database (CRLMOD) data. The CRLMOD data consist of three separate CSIP services: (1) NRCS crop management zone (CMZ) management rotation records, (2) crop/residue records, and (3) operation records. The execution services provided by CSIP for WebStart WEPS consist of: (1) Cligen (Nicks and Gander, 1994) generated daily climate files; (2) Windgen (Wagner et al., 1992; van Donk et al., 2005, 2020) generated hourly wind data files; (3) interpolation routines for Windgen records; and (4) the execution of the WEPS science model.

The third NRCS request was addressed by employing Java WebStart, a framework developed by Sun Microsystems (now owned by Oracle) that allows users to start application software for the Java platform directly from the internet using a web browser. Unfortunately, Oracle removed Java WebStart beginning with Java 11 in 2018. That change has caused us to pursue, at least temporarily, an alternative installation method for WebStart WEPS, when using Java 11 or later versions with a standard Windows MSI package. There are efforts though to provide full Java WebStart functionality again through an open-source project called OpenWebStart as well.

CSIP Services for Remote Data Access

The CSIP services provide connectivity to Colorado State University (CSU) servers containing the data and/or executables required to carry out the intended specific CSIP service functionality. The CSIP remote data service URLs are specified in XML format in the WEPS configuration files (fig. 1).

CSIP Soil

The CSIP soil service provides connectivity to a CSU server that contains a sharded (sharded is a computer science term referring to a method of splitting and storing a single database into multiple databases) copy of the national SSURGO database (USDA-NRCS, 2020), which is a part of the NRCS National Soil Information System (NASIS). WEPS uses the tabular data component elements of the SSURGO database. The following URL CSIP “soil” endpoints are currently used:

Soil catalog: https://csip.engr.colostate.edu:9083/csipsoils/d/wwesoilparams/1.1

Soil record: https://csip.engr.colostate.edu:9083/csipsoils/d/wepssoilinput/2.0

The first CSIP soil endpoint (wwesoilparams) requires polygon (lat/long) coordinates as inputs and returns only a list of soil names (catalog) within the specified polygon region. Because WebStart WEPS currently requires the user to specify only a single lat/long coordinate to locate the field, we assume a square field polygon shape of a size specified in the configuration settings (default is 65 ha or 160 acres) when selecting the soil components residing in the field. This CSIP soil endpoint then returns the actual soil name built from a combination of the returned elements from the soil catalog call. The following elements are used in building the unique soil component file names existing within that field: “areasymbol”, “musym”, “muname”, “comppct_r”, and “compname”. These names are associated with their parameter “cokey” because these are the values sent to the CSIP soil endpoint (wepssoilinput) to obtain the remaining soil data elements. These data are then presented to the user via a dropdown list for selecting the desired representative soil component for the field for use in WEPS.

WEPS caches all CSIP soil data so that they are available for subsequent simulations needs, reducing the need for repeated downloading of soil data for nearby simulations.

CRLMOD (CMZ Management, Operations, and Crops/Residues)

CRLMOD is an NRCS database warehouse for storing and maintaining data for modeling. The WEPS-related data consist of CMZ template management and crop rotation records, individual operation records, and crop/residue growth and decomposition records. The NRCS has defined CMZs across the U.S. that represent regions with similar cropping systems, based on climate, soils, etc. These template files allow quick and easy access to management data that can then be modified for use in WEPS simulation. The CRLMOD operation and crop/residue records represent the available WEPS operations and crops, as well as residues, that can be included in WEPS management rotations.

CSIP Management

The CRLMOD CMZ template management records are accessible using the following URL CSIP “management” endpoint:

https://csip.engr.colostate.edu:9083/csipcrlmod/d/management/4.0

This endpoint is used for obtaining the catalog listing of all available WEPS-compatible management records as well as the selected management record data. This two-step process is used because the list of management records is large, and most WEPS users need access to only a limited number of records. The initial list presents the user with a dropdown list of CMZ management names. The selected management record is then obtained through the CSIP management endpoint to retrieve the selected management record data for WEPS. The selected management records are cached within WEPS to eliminate redundant downloading of the same records and improve response times for management record selections.

CSIP Operations

The CRLMOD WEPS operations records are accessible using the following URL CSIP “operations” endpoint:

https://csip.engr.colostate.edu:9083/csipcrlmod/d/operation/4.0

This endpoint is used to obtain the catalog listing of all available WEPS operation records and the data for the selected operation records based on inputs specified for this endpoint URL. This two-step process is used because the initial list presents the user with a dropdown list of WEPS operation records within the Management/Crop Rotation Editor for WEPS (MCREW). The selected operation record is then obtained through the CSIP management endpoint to retrieve the operation’s data for use in the management/crop rotation sequence being edited in MCREW. In WEPS, all management operation records are downloaded and cached locally during installation to improve responsiveness to operation record selections.

CSIP Crops/Residues

The CRLMOD WEPS crop/residue records are accessible using the following URL CSIP “crop” and “residue” endpoints:

https://csip.engr.colostate.edu:9083/csipcrlmod/d/crop/4.0

https://csip.engr.colostate.edu:9083/csipcrlmod/d/residue/4.0

These endpoints are used for obtaining the catalog listing of all available WEPS crop/residue and residue-only records and the data for the selected crop and/or residue records. This two-step process is used because the initial list presents the user with a dropdown list within MCREW to select WEPS crop/residue and residue-only records. The selected crop/residue or residue-only record is then obtained through the relevant CSIP endpoint to retrieve the crop and/or residue’s data for use in the management/crop rotation sequence being edited in MCREW. In WEPS, all crop and/or residue records are downloaded and cached locally during installation to improve responsiveness to crop and residue record selections.

CSIP Services for Remote Model Execution

In addition to remote data retrieval, the CSIP services provide remote execution functionality. We provided the ability to remotely execute all binaries required to complete a WEPS simulation run. This included the Windgen generator, the interpolation routines for developing a Windgen station if within a specified interpolation region, the Cligen climate generator, and the WEPS science model itself. All data and results for WEPS runs are returned to the client computer.

To maintain consistent results for simulations run locally on Windows-based computers, the CSIP services were originally configured to run Windows binaries for all services. With CSIP services hosted on Linux-based servers, the emulation layer resulted in increased execution times for the

remote services. The WEPS CSIP remote execution services now use native Linux binaries rather than executing Windows binaries through software emulation, resulting in significantly faster service response times. For Cligen and Windgen, we modified the source code and specified appropriate compiler flags, so that identical output files are now produced by both Windows and Linux binaries. For WEPS execution, minor differences can still occur between runs made with a Windows binary versus a Linux binary. WebStart WEPS installs the Cligen, Windgen, and WEPS binary files onto the user’s PC to enable local model execution when internet connectivity is not available. Thus, users can sometimes still get slight differences in results on a Windows PC between a model run made using the CSIP server services versus a run made using local model execution.

To promote testing, code debugging, development, and model execution, these CSIP services can be independently enabled and disabled via the WEPS interface through the Server tab of the Configuration Panel to modify the WEPS configuration file based on specific user needs (fig. 2). An added benefit is that the user can also make offline (local) WEPS simulation runs, assuming that all the necessary input data are available. Thus, the user is not strictly required to maintain an internet connection to use WebStart WEPS.

Figure 2. WEPS Configuration Panel displaying remote service URLs selected and specifying if each service is to be run remotely or locally.

CSIP (Interpolation Routines)

If wind station data need to be interpolated, this can be achieved with the CSIP interpolation routines. Currently, only Windgen station data are interpolated for a specified region in the U.S. (generally east of the Rocky Mountains where orographic effects are less pronounced). The interpolation is performed in two steps. First, the desired interpolated station location (lat/long) is used to determine the three nearest bounding Windgen stations. The CSIP interpolate station selection step returns the three Windgen records and their associated weightings (based on distance) to use for the actual station interpolation step. The CSIP endpoint that executes this first step of the interpolation process is:

https://csip.engr.colostate.edu:9083/csipclimate/m/interpolate/1.0

Second, the actual station interpolation occurs by obtaining the station data from the specified station database (file consisting of the station records). This can be a file included with the CSIP service or station data passed to the CSIP service from the client computer. The CSIP service endpoint that executes the final step of the interpolation process to create the interpolated Windgen station is:

https://csip.engr.colostate.edu:9083/csipclimate/m/interp_wdb/1.0

CSIP (Windgen)

The Windgen CSIP service generates the simulated hourly wind data by executing the Windgen executable with the wind station data. The CSIP service can use the internally provided Windgen records or have the record passed to the service externally. The Windgen CSIP service endpoint is:

https://csip.engr.colostate.edu:9083/csipclimate/m/windgen/1.0

CSIP (PRISM)

The PRISM (Parameter-elevation Relationships on Independent Slopes Model) 4 km spatially gridded conterminous U.S. data set (Kittel, et al., 1997; Daly et al., 1997; PRISM, 2022) is optionally used to modify Cligen station datasets for use in generating WEPS climatic data. The monthly average precipitation and max/min temperatures for the nearest Cligen station are replaced with 30-year values from the 4 km gridded PRISM data for the specified lat/long coordinates. The PRISM CSIP service endpoint that performs this Cligen station data substitution is:

https://csip.engr.colostate.edu:9083/csipclimate/m/cligen_prism/weps/1.0

CSIP (Cligen)

The Cligen CSIP service generates the simulated daily climate data by executing the Cligen executable with the supplied climate station data. The CSIP service can use the internally provided Cligen records or have the record passed to the service externally (e.g., from the PRISM CSIP service). The Cligen CSIP service endpoint is:

https://csip.engr.colostate.edu:9083/csipclimate/m/cligen/1.0

CSIP (WEPS)

The WEPS CSIP service executes the model and sends back the resulting output files to the client computer so that the interface can provide the user with the desired WEPS output in more user-friendly tables and reports. The inputs required include hourly generated Windgen wind data, daily generated Cligen weather data, and a “weps.run” file that consists of the remaining required WEPS inputs (e.g., name and location of the soil and management rotation files). The WEPS CSIP service endpoint is:

https://csip.engr.colostate.edu:9083/csipweps/m/weps/1.0

Java WebStart

The third NRCS request, to initiate WEPS from a web-based URL link, was initially addressed by employing Java WebStart. Java WebStart was an ideal solution for the NRCS because it came bundled as an integral part of Java, provided a one-click delivery, and has an installation mechanism for WebStart WEPS for field office computers that did not require administrator privileges and could ensure that they were running the latest version of an application. However, WebStart security restrictions require applications to be signed to ensure that they have not been externally modified and to provide additional permissions beyond the WebStart defaults, such as reading and writing local files. WebStart applications do not run within a browser. They are independent applications that are not restricted to the constraints of what the browser allows. Thus, we were able to keep the full functionality of the current WEPS desktop interface while retaining the current interface look and feel. We were also able to leverage the current WEPS interface code base, all without rewriting the interface as a native web browser application. Our WebStart implementation works well, where we use it to install our WEPS bootloader code. The bootloader code then downloads and installs (caches) the rest of the WEPS application files.

With the upgrade of Java to version 11, WebStart functionality was removed, making this method of software delivery at least temporarily unavailable for newer releases of Java. That left us with two options for timely delivery of WebStart WEPS with its additional features: (1) hope that the OpenWebStart project matures fast enough to become a default complete drop-in replacement for Java WebStart for all Java distributions, or (2) come up with another installation/delivery option for WebStart WEPS under Java 11 and later Java releases. Fortunately, OpenWebStart has matured sufficiently and now contains all the critical functionality that WebStart WEPS requires to download/install the WEPS bootloader code. However, it is not yet an integral component of any OpenJDK distributions, thus requiring a separate external installation. We have also developed a second viable option. We have created a Microsoft Installer (MSI) build to formally install the WEPS bootloader on client Windows computers. The WEPS bootloader will then download and cache the remaining WEPS components from the specified server, just as is currently done with the Java WebStart (and OpenWebStart) version of WebStart WEPS. Thus, the NRCS has two options available that we support for installing/running WebStart WEPS using current Java releases.

New WEPS Features

In addition to targeting the three main issues identified by the NRCS for the WebStart WEPS release, we provided some additional features, which are described in the following sections.

MapViewer Update

Because users have the option of selecting a soil component based on their site’s location, they either need to precisely specify the site’s lat/long coordinates or select the field location from a map. To provide a suitably detailed map, the USGS satellite imagery layer was added to WEPS MapViewer (fig. 3), allowing users to zoom in and select the field location. The lat/long of the selected point is returned, and the CSIP soil service automatically updates the soil component lists for the field site. The default polygon size is 65 ha (160 acres) around the selected lat/long point to approximate a typical field size. This value can be changed in the Configuration Panel and saved in the WEPS configuration file. Users are still expected to use their own expertise in determining which soil component should be used in the simulation based on NRCS guidelines (e.g., largest extent, most highly erodible); however, if a user wishes to apply the original SoilDataMart option to select a soil component, that option is still available.

The geotools component for displaying images in the WEPS MapViewer was updated to the latest version to accommodate future use with Java 11. That update also forced unit conversion changes throughout the WEPS code as the latest geotools package moved to Java JSR-363 (a JSR is a Java Specification Request) because the older JSR-275 methods were deprecated and incompatible with the new methods. Along with the major geotools upgrade, we made several user interface enhancements to the MapViewer component: (1) we added a zoom in/out slider bar; (2) the interface allows users to select their location and have it identified with a red plus sign (+), which also automatically updates the lat/long location on the main WEPS interface screen; (3) the interface provides real-time display of the lat/long pointed to with the mouse cursor; and (4) we added a “Reset Location” button to revert to the initial lat/long location in the MapViewer window (fig. 3). In addition, we added several Configuration Panel fields to specify the default zoom level, both default and maximum MapViewer window sizes, and allow the user to specify whether the satellite imagery and other layer(s) are to display by default when the MapViewer is selected. Most of these settings were provided to allow users with slow internet access to tweak their configuration to provide the best response when zooming in/out of the satellite imagery layer.

Crop Interval Mode (MCREW)

The NRCS also requested a method to build (create) WEPS-compatible management/crop rotation files from scratch, starting with any management operation in the rotation. WEPS-compatible management/crop rotation files must begin on January 1 of year one of the rotation. Many

farm managers and NRCS field office staff typically think in terms of crop intervals, which are usually considered to begin with the first operation following the harvest or termination of the previous crop. This means that many crop intervals span two (or more) calendar years in a multi-year rotation. Even building a typical annual fall-harvested crop for a single-year rotation means that the crop interval view will span two calendar years. To address this need, we created a Crop Interval Mode display for the Management/Crop Rotation Editor for WEPS (MCREW).

Code was created to automatically handle the conversion between the Crop Interval Mode display (fig. 4) and the standard WEPS Rotation Mode display (fig. 5), so users can switch between the two modes seamlessly. A horizontal black pointer was added to the WEPS Rotation Mode display (fig. 5) to identify which management operation should be the first operation displayed in the Crop Interval Mode display (fig. 4). The user can change the pointer to any operation desired. If a rotation is created in the Crop Interval Mode display, the pointer will automatically be set to that first operation when converted to WEPS Rotation Mode. A few inconsistencies still need to be addressed for Crop Interval Mode to work flawlessly for all cases, but it achieves the desired functionality of allowing users to create a WEPS management/crop rotation file from scratch, starting with any operation in the rotation.

Figure 3. WEPS Map Viewer displaying the USGS satellite imagery layer for easy field selection. Note the zoom level bar, window size, reset location, and Cancel/Done buttons.

Management Rotation Auto-Update (MCREW)

One additional NRCS request was an “auto-update” for all older, previously constructed WEPS management rotation files, so that NRCS field office users would always be using the most current, updated, and vetted CRLMOD management and crop/residue records. Because WEPS already had the built-in capability to update WEPS management files manually, we leveraged that functionality and added specific Config Panel settings to enable/disable the auto-updating, or to allow users to decide which individually selected management files would be auto-updated (fig. 6).

Figure 6. Popup “Out of Date Management File” message, which displays if specified in the WEPS configuration file.

Default QuickPlots

After some initial testing, the NRCS informed us that there was a need for default plots that users could select straight from the main WEPS screen and the user reports (fig. 7). Typically, these plots would be reviewed to determine the period and extent of wind erosion occurring on the simulated site, to ensure that they were achieving the desired protection from cover crops, etc. Because WEPS already had a QuickPlots feature built into the Tabular Detail Report where users could manually select the desired data columns to graph, we leveraged that functionality to provide the predefined Default QuickPlots list from the main WEPS screen’s menu and toolbar, as well as from each of the User Reports. The default QuickPlots are defined within an XML formatted file, so it is relatively easy to modify/expand the list of plots without additional coding required. An example QuickPlot display is shown in figure 8.

Figure 7. Main WEPS interface screen’s QuickPlots menu options.

Additional WEPS Updates

In addition to the new features described in the preceding sections, the WebStart WEPS interface has been made Java 11 compliant and contains updated packages, bug fixes, and interface enhancements. The WEPS science code has also been updated with the new multi-subregion version of the WEPS science model (the current interface can only create a single subregion simulation at this time). The code has been made more modular, with most common blocks removed and subroutines moved into Fortran modules, bug fixes have been applied, and additional outputs have been added to support interface enhancements.

Conclusion and Summary

WebStart WEPS is a natural evolution of the WEPS model that provides an easy install option (Java WebStart) for systems running Java 8. OpenWebStart allows this functionality to again be available for Java 11 and later versions but requires a separate install because none of the OpenJDK distributions currently include OpenWebStart. As an alternative, an MSI installation package for the WEPS bootloader has been made available for Windows computers. Either install approach allows automatic updates with the latest versions of the WEPS interface and science model. The ability to access data remotely via the CSIP services reduces the minimum footprint required to run WEPS because the data do not have to reside on the local computer. Likewise, the ability to execute the climate generators and the science model remotely reduces local storage requirements if users forego the installation of the local PC binaries. In addition, lower-end computers can be used without a significant increase in WEPS runtimes when the remote execution features are employed. Furthermore, users can still execute WEPS runs locally, and can do so even without an internet connection, if desired or necessary. In summary, this release of WEPS provides significant new functionality not previously available, with remote data access and remote execution features, but still provides the same interface and user features available in the 1.5.52 WEPS release.

Figure 8. Example WEPS QuickPlot displaying canopy and residue cover for the first year of a three-year rotation.

References

Daly, C., Taylor, G., & Gibson, W. (1997). The PRISM approach to mapping precipitation and temperature. Proc. 10th AMS Conf. on Applied Climatology (pp. 10-12). Boston, MA: American Meteorological Society.

David, O., Lloyd, W., Carlson, J., Arabi, M., & Wible, T. (2016). Cloud Services Integration Platform (CSIP) model and data services. Proc. 8th Intl. Congress on Environmental Modeling and Software. Manno. Switzerland: International Environmental Modeling and Software Society.

David, O., Lloyd, W., Rojas, K., Arabi, M., Carlson, J., Geter, F., ... Leavesley, G. (2014). Model-as-a-service (MaaS) using the Cloud Services Innovation Platform (CSIP). Proc. 7th Intl. Congress on Environmental Modeling and Software. Manno. Switzerland: International Environmental Modeling and Software Society.

Kittel, T. G., Royle, J. A., Daly, C., Rosenbloom, N. A., Gibson, W. P., Fisher, H. H., ... Berliner, L. M. (1997). A gridded historical (1895-1993) bioclimate dataset for the conterminous United States. Proc. 10th AMS Conf. on Applied Climatology (pp. 219-222). Boston, MA: American Meteorological Society.

Kubernetes. (2021). What is Kubernetes? Retrieved from https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Nicks, A. D., & Gander, G. (1994). CLIGEN: A weather generator for climate inputs to water resource and other models. In F. Watson, S. Zazueta, & T. V. Harrison (Eds.), Proc. 5th Intl. Conf. Computers in Agriculture (pp. 903-909). St. Joseph, MI: ASAE.

PRISM. (2022). PRISM Climate Group. Corvallis, OR: Oregon State University, Northwest Alliance for Computational Science and Engineering. Retrieved from https://prism.oregonstate.edu/

USDA-ARS. (2020). Wind Erosion Prediction System (WEPS): Technical documentation. Beltsville, MD: USDA Agricultural Research Service. Retrieved from https://naldc.nal.usda.gov/catalog/7105679

USDA-NRCS. (2010). Notice of implementation of the Wind Erosion Prediction System for soil erodibility system calculations for the Natural Resources Conservation Service. Federal Register, 75(234), 75961-75962. Retrieved from https://federalregister.gov/a/2010-30673

USDA-NRCS. (2020). Soil Survey Geographic (SSURGO) database. Washington, DC: USDA Natural Resources Conservation Service. Retrieved from https://sdmdataaccess.sc.egov.usda.gov

van Donk, S. J., Tatarko, J., Skidmore, E. L., Wagner, L. E., & Fox, F. A. (2020). Chapter 4: Weather generators of WEPS. In Wind Erosion Prediction System (WEPS): Technical Documentation (pp. 57-84). Beltsville, MD: USDA Agricultural Research Service. Retrieved from https://naldc.nal.usda.gov/catalog/7105679

van Donk, S. J., Wagner, L. E., Skidmore, E. L., & Tatarko, J. (2005). Comparison of the Weibull model with measured wind speed distributions for stochastic wind generation. Trans. ASABE, 48(2), 503-510. https://doi.org/10.13031/2013.18324

Wagner, L. E. (2013). A history of wind erosion prediction models in the United States Department of Agriculture: The Wind Erosion Prediction System (WEPS). Aeolian Res., 10, 9-24. https://doi.org/10.1016/j.aeolia.2012.10.001

Wagner, L. E., Tatarko, J., & Skidmore, E. L. (1992). WIND-GEN: A statistical database and generator for wind data. ASAE Paper No. 92211. St. Joseph, MI: ASAE.

Daly, C., Taylor, G., & Gibson, W. (1997). The PRISM approach to mapping precipitation and temperature. Proc. 10th AMS Conf. on Applied Climatology (pp. 10-12). Am. Meteor. Soc.

David, O., Lloyd, W., Carlson, J., Arabi, M., & Wible, T. (2016). Cloud Services Integration Platform (CSIP) model and data services. Proc. Int. Environmental Modelling and Software Society. Brigham Young University.

David, O., Lloyd, W., Rojas, K., Arabi, M., Carlson, J., Geter, F., . . . Leavesley, G. (2014). Model-as-a-Service (MaaS) using the Cloud Services Innovation Platform (CSIP). Proc. 7th Int. Congress on Environmental Modelling and Software.

Kittel, T. G., Royle, J. A., Daly, C., Rosenbloom, N. A., Gibson, W. P., Fisher, H. H., . . . Berliner, L. M. (1997). A gridded historical (1895-1993) bioclimate dataset for the conterminous United States. Proc. 10th AMS Conf. on Applied Climatology (pp. 219-222). Am. Meteor. Soc.

Kubernetes. (2021). What is Kubernetes? Retrieved from https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Nicks, A. D., & Gander, G. (1994). CLIGEN: A weather generator for climate inputs to water resource and other models. In F. Watson, S. Zazueta, & T. V. Harrison (Ed.), Proc. 5th Int. Conf. Computers in Agriculture (pp. 903-909). St. Joseph, MI: ASAE.

PRISM Climate Group, Oregon State Univ. (2022). Retrieved from https://prism.oregonstate.edu/

U.S. Gov. (2010). Federal Register, 75(234), 75961-75962. Retrieved from https://federalregister.gov/a/2010-30673

USDA Soil Survey Staff, NRCS-USDA. (n.d.). Soil Survey Geographic (SSURGO) Database. Washington, DC: USDA-NRCS. Retrieved from https://sdmdataaccess.sc.egov.usda.gov

USDA-ARS. (2020). Wind Erosion Prediction System (WEPS): Technical documentation, USDA agriculture handbook 727. (J. Tatarko, Ed.) Beltsville, MD: USDA-ARS. Retrieved from https://naldc.nal.usda.gov/catalog/7105679

van Donk, S. J., Tatarko, J., Skidmore, E. L., Wagner, L. E., & Fox, F. A. (2020). Chapter 4: Weather generators of WEPS. In J. Tatarko (Ed.), Wind Erosion Prediction System (WEPS): Technical Documentation, USDA Agriculture Handbook 727 (pp. 57-84). Beltsville, MD: USDA ARS.

van Donk, S. J., Wagner, L. E., Skidmore, E. L., & Tatarko, J. (2005). Comparison of the Weibull model with measured wind speed distributions for stochastic wind generation. Trans. ASABE, 48(2), 503-510. doi:https://doi.org/10.13031/2013.18324

Wagner, L. E. (2013). A history of Wind Erosion Prediction Models in the United States Departmentof Agriculture: The Wind Erosion Prediction System (WEPS). Aeolian Res., 10, 9-24. doi:https://doi.org/10.1016/j.aeolia.2012.10.001

Wagner, L. E., Tatarko, J., & Skidmore, E. L. (1992). WIND-GEN: A statistical database and generator for wind data. ASAE Paper No. 92-211. St. Joseph, MI: ASAE.