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.
LSM Parameter Processing
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.).
A 'spatial transform' entry in the run-time LDT configure (e.g., ldt.config) file allows the user to specify how a parameter file can be 'transformed' or translated from its 'native' or original projection and resolution to the designated LIS target grid projection and resolution.
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.
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.