This website houses data from "version 1" of the Iowa Daily Erosion Project. This website is now deprecated. Please check out our "version 2" Daily Erosion Project.

Erosion Modelling Procedure

This page outlines the procedure by with erosion estimates are generated by this project. Please don't hestitate to contact us if you have any questions.

1. Modeling components:

Our erosion estimates are produced from the WEPP model. WEPP needs a host of inputs in order to make its estimates. These inputs are listed here:

  • Rainfall and climate information.
  • Characteristics about the land and its management.
  • Characteristics of the management practices.

Numerically speaking, the raw counts for each component are:

Count: Component:
1850 Model townships
2188 Different manangements
7988 HRAP cells which contain breakpoint rainfall and climate information
17848 Number of NRI points used
90494 Number of combinations of HRAP cells and NRI points used in our modelling effort

Determining managements:

The NRI dataset provides us with management information for the years of 1994, 1995, 1996, and 1997. Our modeling effort begins with the year 1997 and continues through 2004 (8 years). This means that the four years of managements provided by the NRI dataset are repeated to cover the 8 years. Like so:

Model Year:NRI Year:
19971997
19981994
19991995
20001996
20011997
20021994
20031995
20041996

2. Cross referencing the components:

For our modelling effort we are using NRI point data which is given to us with township location information and rainfall information which is given to us on a HRAP grid which is not coincident with the townships. This creates somewhat of a problem when trying to combine rainfall cells with NRI points we wish to run WEPP for. Our procedure is to run the total combination of NRI points and HRAP cells within each township to produce a presentative estimate of erosion on the scale of a township.

3. Our daily erosion estimates:

At 12:45 AM each morning, our modelling system (hereafter: WEPP) is invoked and begins the process of modelling yesterday's erosion. The first step is to request yesterday's precipitation (hereafter: rainfall) information from the University of Iowa's IIHR lab. If this data is not available, the system sleeps for a while before attempting again. Once the data has been downloaded, the rainfall estimates are processed.

Processing rainfall estimates:

The rainfall dataset contains 15 minute estimates of rainfall intensity. These intensities are processed as if they are actual accumulations, which is a reasonable assumption. The rainfall information is made available on a grid of HRAP cells. These cells are checked for rainfall intensities over 5mm/hr and if found, breakpoint information is generated for WEPP and the system 'remembers' these points for later processing. If smaller intensities are found, 1 breakpoint is generated just to make sure the water balance is accounted for.

This newly processed breakpoint information is merged with our archive of climate and previously processed breakpoint rainfall data. Climate files suitable for WEPP are then generated and the system is ready to start executing the WEPP model.

Running the model:

A python script called proctor.py manages the execution of the WEPP model. The script interfaces with the database and generates all of the WEPP input files needed to make runs. Once all of the runs queued for the day are finished, a post-processor parses all of the output files and mines the data away in the database.

Cleaning up:

Some system accounting and file clean up is done when the modelling is complete. Most of these tasks are not worth mentioning here.

4. Model Runtime

If all combinations are to be run, the model will take 12 hours to finish on the current hardware we are using. This does not fit with the timeline of having yesterday's erosion estimates completed by the next morning. The system has been designed to be distributed to other systems so that multiple machines can be simulataneously working to complete the job queue. Unfortunately, the system is more IO-bound than CPU-bound, so throwing more processors at the task does not help much. Changes are coming to the system to spread the diskIO out to more machines.