All of our LIS code is now publicly available on GitHub!  Please visit our LIS framework (LISF) GitHub page to download the latest version.

 

You can download the entire LISF suite as a zipped tarball download (by clicking on the green "Clone or download" button), or you can checkout the LISF code repository via GitHub to your local server or machine. You can review the following documentation on getting familiar with GitHub and accessing LIS from there: Click here for more info!

To learn more about LIS, please see our main LIS page, and visit the different pages about LDT, LIS and LVT at the above "About" pull-down menu.

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

Each software component of the LIS framework requires a few libraries, including:

 

For more information on what libraries are required, please visit our Documentation page and LISF GitHub pages.

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

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).

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.

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.

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.

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).

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.