Sorry, you need to enable JavaScript to visit this website.

LSM Parameter Processing

How does topographic downscaling of the bottom temperature field work?

To capture some of the impact of terrain relief on bottom soil temperature field variability, you can turn the 'Bottom temperature topographic downscaling:' entry in the ldt.config file to "lapse-rate". You will also need to also turn on and read in an elevation map, preferably of higher resolution than your bottom temperature map. Then using the elevation file and the environmental lapse rate (~6.5 K/km), the bottom temperature file values are adjusted by the elevation values, representing what the soil temperature might reflect at a higher or lower elevation.

What are the 'fill' options (e.g., fill radius)?

The 'fill' options associated with each parameter entry in the LDT config file provide the user the ability to make sure the read-in or derived landmask and the read-in parameter files agree (i.e., same number of land points). Continuous type parameter files can utilize either 'neighbor' or 'average' options in using neighboring pixels to 'fill' in a missing parameter value when there is an actual valid land point (i.e., landmask = 1). Discrete data types can only use 'neighbor' option at this time (e.g., landcover, soil texture, etc.).

What is the 'LIS' data format type?

The other type of data read in by LDT includes the LIS team processed files referred to commonly as 'LIS' data. These original files are 4-byte real, big-endian, direct access, binary format, with the extension: *.1gd4r . One downside to using these datasets is that many of them have the "UMD" landmask imposed on all the parameter files, forcing users to use this older mask in their model runs. LDT, LIS and LVT are moving away from this data formatted file use.

What are the 'Native' data files?

When LDT was being developed, the LIS team decided to provide two pathways for the LIS user community for how data parameters can be read in to LDT and LIS-7. The first being that any original or 'native' model parameters and data provided by a government agency, university, organization, etc. should be read in "as-is" and not have any preprocessing done to the files. This "philosophy" is intended to better preserve the original data information and pixel integrity but also allow the user to select how the parameters get processed for their modeling needs.