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

Frequently Asked Questions

General

To learn more about LIS, please see our "about" page here.
Currently, several map projections are supported for both input parameters and the LIS target run grid. These include: 'latlon', 'lambert' (for lambert conformal), 'polar' (for polar stereographic), 'hrap' (for HRAP, a flavor of polar stereographic), 'mercator', and 'gaussian' (which is supported in LDT and will be for LIS-7 in future releases). Other projections, like 'UTM', will also be supported in future releases.
The current public versions of LIS support the following LSMs:

  • Noah 2.7.1
  • Noah 3.2
  • Noah 3.3
  • Noah 3.6
  • Noah 3.9
  • Noah Multi-Physics (MP), version 3.6
  • Catchment LSM (CLSM), Fortuna 2.5 version
  • VIC 4.1.1
  • VIC 4.1.2
  • SAC-HTET/SNOW-17
  • GeoWRSI 2.0
  • CLM 2.0
  • Mosaic
  • HY-SSib

Computing Requirements

Yes, depending on the amount of memory and cores you have.

LSM Parameter Processing

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. This feature helps then give more detail in mountainous areas and capture local minimum temperatures in the soil temperatures than if not accounted for.
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.). Additional options include the 'fill radius' which the user can enter the number of row/column pixel area to search for neighboring valid parameter values. If no neighboring values are found (e.g., could be an island), the user can specify a 'generic fill' value for that given parameter (e.g., input the land class of 6 for the landcover parameter).
With LDT, LIS users can either "readin" an existing land-water mask or "create" one from the landcover map that is read in (e.g., a landmask derived from MODIS-IGBP, ESA). For most of LIS' history, most users were restricted to using just the "UMD" landmask, which came from the AVHRR satellite-based UMD classification map, circa 1992-1993. Today, LIS users have several different landcover datasets and classifications they can chose from, and from which they can create landmasks. Also, any other landmask can be read in, like the MODIS-based MOD44w landmask product, which is now used in the MODIS Collection 6 products.
 
Because reading in or creating a landmask map may not share matching land points with other parameter maps read in (e.g., soil texture, elevation), "fill" options are provided in LDT to help ensure agreement  between the mask and the parameter fields. These "fill" routines are based on earlier code used to impose the "UMD" landmask on all of the original LIS-team produced binary files (aka, the "LIS-data" files). Also, the "fill" step occurs on the LIS output run domain after the spatial transform step is performed.
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.
 
For example, you want to upscale your 0.01°, lat-lon grid landcover file to a 0.25°, lat-lon grid map. You can select 'tile' as the entry for the 'Landcover spatial transform:' option, and LDT will aggregate the landcover pixels to tile layers (i.e., fraction of each landcover type) within each 0.25° output gridcell. If you were to select 'mode' instead here, a value of "1" would be assigned to the most dominant vegetation layer, representing 100% coverage. Since landcover is a discrete data type, you would not want to select interpolation methods, like 'bilinear', or upscaling option, 'average' (or you would end up with a landcover type of 4.331!).
 
For a downscaling example, you could have a 1.0°, lat-lon grid albedo map and you want to run on a 0.25°, lat-lon output grid. You could select 'bilinear' for interpolating the coarser albedo parameter map to the finer scale 0.25° map.
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.

Data Assimilation (DA) Input Preprocessing

Currently, LDT can estimate the statistics required to do a simple bias-correction or scaling approach between similar observational data and model state estimates to reduce bias between the two during assimilation update step. LDT generates the mean, standard deviation and cumulative (probability) density function (CDF) values, which LIS-7 ingests to perform the final CDF "matching" between the observations and the model estimates.
The current public LIS versions support the following data assimilation (DA) observation dataset types:

  • Soil Moisture Active Passive (SMAP) soil moisture products
  • NASA/Vrije U. Land Parameter Retrieval Model (LPRM) AMSR-e Soil Moisture data
  • NASA/NSIDC AMSR-e Soil Moisture data
  • Essential Climate Variable (ECV) Satellite-based Soil Moisture analysis
  • TU Wien ASCAT Soil Moisture (retrospective)
  • NESDIS/OSPO Soil Moisture Operational Products System (SMOPS) Soil Moisture product
  • WindSat satellite-based Soil Moisture Retrievals
  • GRACE Terrestrial Water Storage (TWS) Estimates
  • Synthetic Model-derived Soil Moisture output
One method for reducing systematic biases between the observational data to be assimilated and the model's state estimates to be updated with that data is known as "CDF matching". The cumulative density function, or aka the "CDF", characterizes the cumulative probability of a random variable (say, X) up to a specific point that is equal to the desired area under the associated PDF curve, for example left of that specific point. To reduce the bias between the observations of interest and model state estimates, a set of CDF statistics are generated for both the observations and model estimates, respectively. The goal then is just before the assimilation step to use these respective CDF statistics to "match" and scale the observations closer to the model estimates. LDT and LIS-7 follow the approach of Reichle and Koster (2004). We recommend reading this journal article to better understand this CDF matching approach described.

Ensemble Restart Processing

An ensemble restart file includes not only one single realization's set of model state variables required to initialize a LIS model run but several realizations, or ensemble members, to restart a multi-member or open-loop simulation.
Upscaling: refers to expanding a single-member (or realization) LIS-generated restart file to an ensemble of members (or model realizations) that can be used for ensemble model runs. This feature could be helpful to someone interested in performing a simulation of an ensemble of model realizations or data assimilation, but have only model member run for one single realization.
Downscaling: refers to averaging or collapsing a multi-member (or -realization) LIS-generated restart file to a single member (or model realization), making it essentially a climatological realization of the member (ensemble mean simulation).