This box searches only this space. The box at the upper right searches the entire iPlant wiki.

Skip to end of metadata
Go to start of metadata

Stake holders:

 National Critical Zone Observatory Santa Catalina Mountains / Jemez River Basin

Contact:

Tyson Swetnam, tswetnam@email.arizona.edu, (520) 247-2293

Deliverables:

Feature 1: A script which downloads daily weather observations from the DAYMET website when a user generates a LiDAR derived DEM in OpenTopography or USGS National Elevation Dataset.

Midterm Project Status: Completed! Demonstrated several scripts for downloading DAYMET data. 

Final project Deliverables:

  • Modify to allow the user to download DAYMET weather data using any *.TIF file DEM - this should include any DEM's from the USGS National Elevation Dataset.
  • Develop a GUI for a user to select a DEM *.TIF from their hard drive and select specific sets of the DAYMET weather data.
    • Ideally, this should work with GRASS and r.mapcalc (see Feature 2 below) so the user can also generate long term averages, e.g.mean daily or monthly for each year and all years. 

Feature 2: Porting of GRASS GIS tools (i.e. the solar insolation model r.sun & raster map calculator r.mapcalc) to run on a HPC or FutureGrid

Midterm Project Status: Incomplete - limited functionality demonstrated for HPC.

Final Project: 

  • Demonstrate functionality of distributed processing for r.sun across an entire year (365 days with 0.05 hour time step) using any reference DEM.
  • Demonstrate functionality of distributed processing for r.mapcalc for upscaling the DAYMET weather with the higher resolution DEM.
  • Demonstrate functionality of distributed processing for r.mapcalc for generating the two models of EEMT (see Feature 3 below).

Feature 3: Two models of the available free energy doing work on soils [so called Effective Energy and Mass Transfer (EEMT)-Traditional and EEMT-Topographic]

Midterm Project Status: Incomplete - limited functionality demonstrated for HPC. 

Final Project:

  • A GUI tool that allows the user to input a location (the DEM *.TIF) to create the models and saves them on a Datastore (like iPlant) and packages them as .tar or .zip to then be downloaded.
  • Production of EEMT-Traditional and EEMT-Topographic models for all of the Critical Zone Observatory locations on OpenTopography.

Each deliverable should have associated with it:

  • Complete metadata
  • Simple tutorials that earth scientists can follow
  • Explanations of the limitations to the tools (processing, data storage, etc)

Intro Presentation (on PREZI.com) that explains what LiDAR is: 

Background on the science and a concept map with embedded links (PREZI):

concept_prezi.png
 

Links to:* Concept Map * Running a GIS in the Terminal, and * Upscaling Climate data w/ equations* Data Sources* Downloading OpenSource GIS 

  • No labels

4 Comments

  1. Questions you may want to consider (generally, when working with clients/stakeholders):

    • Where are the data?
    • How do I get the data?
    • What are the computations?
    • Are the algorithms already written?
    • Can I run them on linux?
    • How can I break up the data?
    • How can I break up the computation?
      • Is there an optimum for how data is broken-up/time to compute (e.g., very short computations get massive overhead from staging data/getting compute core)
    • What do I need to do for benchmarking?
      • Number of CPUs per computation
      • Amount of RAM per computation
      • Amount of HD space for data/results per computation
    • What other limitations may I run into?
      • File system file limit? etc.
  2. Playing around with the single pixel extraction from daymet. I was thinking one would need four values to pull a single-pixel value from daymet. Two coordinates from Upper-left and then two more for bottom-right, and the area between that would be the data I'm filtering for.

    So is it that at a certain decimal place of a long/lat coordinate equals a 10m square?

    1. A couple points:

      (1) the single pixel extraction tool will not give you enough data for an area larger than 1 square kilometer. Also, it may not be aligned over the same pixel, so you'd need up to 4 pixels for a single square kilometer. It might be more beneficial to use the tile extraction tool which uses 2 degree by 2 degree areas.

      (2) the wget and curl commands only need a single coordinate to extract the data - that might mean you need to use the centroid point [e.g. UTM_center = (UTM_left - UTM_right / 2) + UTME_left]

      example wget command:              

      $ wget 'http://daymet.ornl.gov/data/send/saveData?lat=43.1&lon=-85.3&measuredParams=tmax,tmin&year=2012,2013'

      all parameters  

      $ wget 'http://daymet.ornl.gov/data/send/saveData?lat=43.1&lon=-85.3&year=2012,2013'

      one parameter, all years              

      $ wget 'http://daymet.ornl.gov/data/send/saveData?lat=43.1&lon=-85.3&measuredParams=prcp'

      example curl command:                 

      $ curl 'http://daymet.ornl.gov/data/send/saveData?lat=43.1&lon=-85.3&measuredParams=tmax,tmin&year=2012,2013'

      all parameters  

      $ curl 'http://daymet.ornl.gov/data/send/saveData?lat=43.1&lon=-85.3&year=2012,2013'

      one parameter, all years:               

      $ curl 'http://daymet.ornl.gov/data/send/saveData?lat=43.1&lon=-85.3&measuredParams=prcp'

  3. Does anyone have an example for how to get r.slope.aspect working?  We can get it all going in QGIS but from the grass console/commandline it keeps throwing an error that it cant read the raster header file.