Community Radiative Transfer Model (CRTM)

Jun. 29, 2005 Update

Note: This is an incremental update. Not all dependent codes/tarballs have been updated.

User Interface: Surface structure update.
- Removed the Type component. The coverage fractions are now used in application code to determine the gross surface type.
- The Binary I/O module has been modified according to the Surface structure change, but the file format remains the same.
User Interface: GeometryInfo structure update.
- Added more angle components as well as components that are derived (e.g. degrees to radiances conversion, secant calculation) from the user specified angle components.
- The function CRTM_Compute_GeometryInfo has been added to the CRTM_GeometryInfo_Define module to compute the angle-derived components.
The CRTM_Parameters module was updated to reflect changes in the GeometryInfo structure.
Developer Interface: SfcOptics structure and application module update.
- Added the Surface_Temperature component to the SfcOptics structure.
- Added subroutines to the CRTM_SfcOptics module to compute the weighted average surface temperature from the various surface types and their coverage fraction.
- Updated the SfcOptics application functions with calls to wrapper functions for sensor (microwave and infrared) and surface type (land, water, snow, and ice) specific algorithms. Each set of functions (forward, tangent-linear, and adjoint) is containined within its own module.

The Community Radiative Transfer Model (CRTM) under development at the Joint Center for Satellite Data Assimilation (JCSDA) is an important component in the NOAA/NCEP data analysis system. External research groups funded by JCSDA have also been making their contributions to its development. In order to help the developers to understand the requirements from the analysis system and to reduce the inconsistencies among the components developed by various groups, this web page will serve as an online source for information about the software framework for the development of the CRTM.

The main goal of this CRTM framework is to provide developers, and users, with the information, examples, and utilities necessary to produce software that is flexible (in both development and usage), understandable, and easily maintained.

The CRTM framework breaks the radiative transfer model into components (e.g. gaseous absorption, scattering, surface optics); each of which defines its own data structure and algorithm modules to faciliate independent development of each component. This characterisation is obviously an ideal one since there are dependencies -- in terms of both the physical problem being solved and in software details such as data sharing -- that will not allow every component to be developed in isolation from the others. So, this is not intended to be a replacement for necessary dialogue between developers, but to provide some form of "big picture" for all those involved to minimise or eliminate potential software conflicts and/or redundencies.

Due to the complexity of the radiative transfer problem and the difficulty of balancing the code efficiency and flexibility, we fully anticipate problems arising when the framework is applied in the development process. We sincerely welcome comments and suggestions for its improvement.

Conventions

The following are conventions that have been adhered to in the current release of the CRTM framework. Please note that they are guidelines intended to make understanding the code at a glance easier, to provide a recognisable "look and feel", and to minimise name space clashes. They are not intended to be requirements imposed from on-high onto developers.

Naming of Structure Types and Instances of Structure

The structure type naming convention adopted for use in the CRTM is,

[CRTM_]<name>_type

where <name> is some sort of identifier that indicates for what a structure is to be used. All structure type names are suffixed with "_type" and CRTM-specific structure types are prefixed with "CRTM_". Some examples,

  SpcCoeff_type
  CRTM_Atmosphere_type
  CRTM_AtmScatter_type

An instance of a structure is then referred to via its <name>, or some sort of derivate of its <name>. Some structure declarations examples are then,

  TYPE( SpcCoeff_type )        :: SpcCoeff
  TYPE( CRTM_Atmosphere_type ) :: Atmosphere, Atmosphere_AD
  TYPE( CRTM_AtmScatter_type ) :: AtmScatter, AtmScatter_AD

where the adjoint structure variables are identified with an "_AD" suffix.

Naming of Definition Modules

Modules containing structure type definitions are termed definition modules. The naming convention adopted for definition modules in the CRTM is,

[CRTM_]<name>_Define

where, as with the structure type names, all definition module names are suffixed with "_Define" and CRTM-specific definition modules are prefixed with "CRTM_". Some examples,

  SpcCoeff_Define
  CRTM_Atmosphere_Define
  CRTM_AtmAbsorption_Define
  CRTM_AtmScatter_Define

The actual source code files for these modules have the same name with an ".f90" suffix.

Naming of Application Modules

Modules containing the routines that perform the calculations for the various components of the CRTM are termed application modules. The naming convention adopted for application modules in the CRTM is,

CRTM_<name>

Some examples,

  CRTM_AtmAbsorption
  CRTM_SfcOptics

An exception to this convention is for the scattering application code. Separate modules have been provided to contain the aerosol and cloud absorption/scattering code,

  CRTM_AerosolScatter
  CRTM_CloudScatter

Both of these modules use the AtmScatter structure definitions. For more details, see the AtmScatter section in the Developer's Interface.

Again, the actual source code files for these modules have the same name with an ".f90" suffix. Note that not all definition modules have a corresponding application module since some structures (e.g. SpcCoeff and Atmosphere structures) are simply data containers.

This page maintained by Paul van Delst

Last updated $Date: 2005/06/29 16:52:37 $