Leaf area indices in GEOS-Chem

From Geos-chem
Revision as of 14:56, 10 April 2012 by Bmy (Talk | contribs) (LAI used by dry deposition and soil NOx emissions)

Jump to: navigation, search

NOTE: Page under construction

On this page we provide an overview of how leaf area index (LAI) data is used in GEOS-Chem. Leaf area index is defined as the total leaf surface area divided by the total surface area of a grid box (typical units are: cm2 leaf cm-2 GEOS-Chem grid box).

Also be sure to see our MODIS leaf area indices page, which describes the leaf area indices derived from the MODIS satellite instrument.

Overview

Prior to the official release of GEOS-Chem v9-01-03, GEOS-Chem used leaf area index data in the following manner:

LAI used by dry deposition and soil NOx emissions

As of this writing (April 2012), GEOS-Chem currently uses leaf area index (LAI) data from separate sources. The dry deposition and soil NOx emissions modules utilize the data stored in ASCII files named lai*.global. These files (one per month) are created (using offline IDL routines) for each specific GEOS-Chem grid configuration (i.e. 4° x 5°, 2° x 2.5°, and 0.5° x 0.666° nested grids, etc.). The lai*.global files are read from disk by routines readlai.F and rdlai.F, which save the LAI data into arrays named XLAI (in CMN_DEP_mod.F) and XYLAI (in CMN_VEL_mod.F).

The XLAI and XYLAI arrays store the leaf area index as a function of Olson land type (cf Olson 1992 land map). The XLAI array has dimensions (IIPAR,JJPAR,NTYPE), where IIPAR is the number of longitudes in the horizontal grid, JJPAR is the number of latitudes, and NTYPE is the number of individual Olson land types per each GEOS-Chem grid box. The XYLAI array contained the same data as in XYLAI, but for historical reasons was dimensioned with only one spatial dimension: (IIPAR*JJPAR,NTYPE).

Please note that there is a direct correspondence between the LAI data stored in the lai*.global files (and saved into XLAI and XYLAI arrays) and the Olson land map. Therefore, if you are using the Olson 1992 land map (native resolution 0.5° x 0.5°, default in GEOS-Chem), then you must also use LAI data at 0.5° x 0.5° native resolution. On the other hand, if you are using the Olson 2001 land map (native resolution 0.25° x 0.25°), then you must also use LAI data at 0.25° x 0.25° resolution.

GEOS-Chem users had the option to use either LAI data from the AVHRR satellite instrument or the MODIS satellite instrument. Individual sets of lai*.global files were prepared for both AVHRR LAI and MODIS LAI data. Users could select either AVHRR LAI or MODIS LAI with a switch in the input.geos file. Customary usage is to select the MODIS LAI data, for reasons explained HERE.

LAI used by MEGAN biogenic emissions

The MEGAN biogenic emissions module also relies on MODIS LAI data. Routine RDISOLAI (in lai_mod.F) reads MODIS LAI at 1° x 1° native resolution from files in binary punch format. The LAI is regridded on-the-fly to GEOS-Chem resolution and stored in arrays named ISOLAI (daily LAI), PMISOLAI (LAI for previous month), MISOLAI (LAI for this month), and NMISOLAI (LAI for next month), all in lai_mod.F. The MEGAN module gets the MODIS LAI data directly from these arrays.

Also, when modifications were made for the GEOS-5 0.5° x 0.666° nested grids, separate subroutines were added into lai_mod.f to read from LAI data sets that were specifically regridded to each 0.5° x 0.666° nested grid window (China/SE Asia, N. America, and Europe). This adds another layer of complexity on top of an already overburdened code.

Issues that needed to be resolved

These different sources of LAI data (i.e. one data set stored in the lai*.global files at GEOS-Chem resolution, one data stored in binary files at 1° x 1° native resolution, and the special data sets for the 0.5° x 0.666° nested grids) present an inconsistency that should be resolved as GEOS-Chem development continues to advance.

Furthermore, for the Grid-independent GEOS-Chem project we must migrate away from ASCII files (which prevent efficient interfacing with external GCMs). We also cannot assume any particular horizontal grid, since that is now to be specified by the external GCM. Therefore, we must instead read the LAI data from disk at the same native resolution, and from this, populate the arrays that are used by the dry deposition, soil NOx emissions, and MEGAN biogenic emissions modules.

Finally, to facilitate simulations at ultra-fine horizontal resolution, we will eventually adopt the Olson 2001 land map, which has a native resolution of 0.25° x 0.25°. We will also use an updated version of the MODIS LAI data at 0.25 x 0.25 resolution. We need a flexible mechanism that will allow us to switch between LAI data at different native horizontal resolutions.

Solution

To resolve these issues, we (the GEOS-Chem Support Team) have created a new module (modis_lai_mod.F90) which reads MODIS LAI data from netCDF files at its native resoluton (either 0.5° x 0.5° or 0.25° x 0.25°, depending on which data set is selected) and regrids it to the current GEOS-Chem resolution. The XLAI array is populated for backwards compatibility with the legacy dry deposition and soil NOx emission codes. Also, the LAI arrays from lai_mod.F that are needed for MEGAN biogenic emissions (e.g. ISOLAI, PMISOLAI, MISOLAI, and NMISOLAI) are now replaced with arrays from modis_lai_mod.F (e.g. GC_LAI, GC_LAI_PM, GC_LAI_CM, and GC_LAI_NM).

We have validated that the new scheme generates identical XLAI arrays w/r/t the old scheme. The arrays GC_LAI etc. differ from the ISOLAI etc. arrays slightly (but generally agree to within 0.001). This is due to the fact that the ISOLAI arrays were regridded from 1° x 1° native resolution, but now we are regridding from much finer resolution (either 0.5° x 0.5° or 0.25° x 0.25°).

We have also taken the opportunity to replace the obsolete XYLAI array with XLAI, which will allow us to retire the obsolete legacy code module CMN_VEL_mod.F. We will keep the XLAI array for compatibility with the dry deposition module for the foreseeable future (at least until the dry deposition module is rewritten accordingly).

--Bob Y. 10:55, 10 April 2012 (EDT)

Implementation