Integrating Community RT Components into JCSDA CRTM Yong Han, Paul van Delst, Quanhua Liu, Fuzhong Weng, Thomas J. Kleespies, Larry M. McMillin

Outline Part I Project objective Approach CRTM components CRTM implementation status Plans Issues Part II CRTM framework (Paul van Delst) JCSDA 3rd Workshop on Satellite Data Assimilation, April 2005

Project Objective Fast and accurate community radiative transfer model to enable assimilation of satellite radiances under all weather conditions

Approach Integrate community RT components Provide CRTM framework to the community to minimize efforts in integrating RT components into the CRTM Interact with the community research groups during the integration process: assisting implementation and modifying the framework to accommodate their needs.

CRTM Components Forward CRTM Surface Emissivity/Reflectivity Model(s) Aerosol Absorption/Scattering Model Gaseous Absorption Model Cloud Absorption/Scattering Model RT SolutionSource Functions public interfaces CRTM InitializationCRTM DestructionJacobian CRTM

CRTM Framework By Nov. 2004, the framework for both forward and Jacobian models was completed and distributed together with the documents. The framework details user and developer interfaces, data structures and program layouts The community is now using the framework as a vehicle to integrate RT components into the CRTM

Gaseous Absorption Module Function: provide gaseous (water vapor, Ozone, dry gases, etc.) optical depth profiles Models: OPTRAN and OSS (AER) Integration status: –OPTRAN forward, Tangent-linear and Adjoint models have been integrated with the CRTM framework and tested. –OSS forward model has been preliminarily integrated with the CRTM framework; OSS- and OPTRAN-based CRTMs

Channel Loop Gaseous Optical depth (OPTRAN) RT Solution Channel loop done? yes no channel i R_ch i {R_ch 1, R_ch 2, …, R_ch n } OPTRAN-based CRTM flowchart CRTM Initialization Cloud optical parameters Aerosol optical parameters Surface emiss. & reflect. OPTRAN transmittance coefficients Cloud optical parameter lookup tables Aerosol optical parameter database Surface emissivity and reflectivity database Computer memory

Node Loop Gaseous Optical depth (OSS) RT Solution Loop over those channels engaged with node i Channel loop done? R_ch k = R_ch k + w k R i Node loop done? yes no Node i {R_ch 1, R_ch 2, …, R_ch n } Cloud optical parameters Aerosol optical parameters Surface emiss. & reflect. CRTM Initialization OSS OD lookup table Cloud optical parameter lookup tables Aerosol optical parameter database Surface emissivity and reflectivity database Computer memory OSS weights & node-channel map Computer memory OSS-based CRTM flowchart

Surface Emissivity & Reflectivity Models Microwave: Land – LandEM (Weng et al., 2001) Snow and sea ice (Yan & Weng, 2003) Ocean – wind vector dependent ( Liu and Weng, 2003); wind speed dependent ( English, 1998) Infrared: Ocean – IRSSE (van Delst, 2003; Wu-Smith, 1997) Land – measurement database for 24 surface types in visible and infrared (NPOESS, Net Heat Flux ATBD, 2001) - regression method Integration into CRTM will be completed in June, 2005

Cloud optical parameter module NESDIS/ORA lookup table (Liu et al., 2005): mass extinction coefficient, single scattering albedo, asymmetric factor and Legendre phase coefficients –IR: spherical particles for liquid water and ice cloud (Simmer, 1994); non-spherical ice cloud (Liou and Yang, 1995; Macke, Mishenko et al.; Baum et al., 2001). –MW: spherical particles for rain drops and ice cloud (Simmer, 1994). Integration with CRTM will be completed in June

Aerosol optical parameter module The initial version includes only dust aerosol absorption (no scattering) - aerosol optical depth profile (NASA GSFC). Integration into the pCRTM (current operational RTM) is completed; integration with CRTM is underway.

RT Solution Module Four RT solvers being integrated into CRTM Solve RT equations for a plane-parallel, multiple-layer atmosphere

RT Solution Module UW Successive Order of Interaction (SOI) –Truncated doubling technique to compute layer transmission, reflection and source functions; SOS (successive orders of scatterings) to integrate emission and scattering events from surface to the top of atmosphere (Heidinger et al., 2005), IR and MW. –Forward, tangent-linear and adjoint models. –The three models have been preliminarily integrated with the CRTM framework.

RT Solution Module NOAA/ETL Discrete-ordinate tangent linear radiative transfer model (DOTLRT) –Matrix operator method to compute layer transmission, reflection and source function, adding method to combine layers and surface (Voronovich et al., 2004), IR and MW. –Forward and Jacobian models and HG phase function lookup table –Codes were received in February with the DOTLRT integrated with an earlier version of the CRTM framework (forward interface only). Now ETL is revising the codes.

RT Solutions (cont.) UCLA vector  -4 stream model –Delta-4 stream algorithm to compute layer transmission, reflection and source function analytically; adding method to combine layers and surface (Liou et al., 2005), IR and MW. –Forward and Jacobian models. –Forward model is being integrated into CRTM.

RT Solutions (cont.) NESDIS/ORA Vector DIScrete-Ordinate Radiative Transfer (VDISORT) –Solve for full polarimetric vector, multiple stream radiative transfer equation with polarization from surface and atmosphere as well as their interaction (Weng and Liu, 2003), VIS, IR and MW. –Forward and Jacobian models. –Forward model integration will be completed in June –Will be used as a benchmark and research tool

Plans By the end of June, 2005, a beta version CRTM will be completed with the following components: –Gaseous absorption modules: OPTRAN and OSS if completed –Cloud optical parameter databases: ORA and ETL lookup tables –Surface emissivity and reflectivity module with LandEM, MW SeaIce/Snow emissivity model, MW Ocean emissivity model, IRSSE, and IR land emissivity database. –RT solution modules: VDISORT and the following modules or programs if completed: UW SOI, ETL RT Solver and UCLA Vector Delta-4 Stream.

Plans (cont.) CRTM test and assessment Before passing the CRTMs to the data assimilation system for impact evaluation, we will work with the community to test and assess the CRTMs for (1) software reliability, stability and maintainability (2) model accuracy (3) computation efficiency (4) memory use Note that we assume the developers will fix software bugs and any other deficiencies in their codes. To test the software and models, we will soon provide a set of model inputs including surface data for ocean, land, snow, and ice, and profiles of temperature, water vapor, ozone, water, ice and aerosol parameters. We will also provide theoretical results for comparisons. Data may be created by LBLRTM and VDISORT, or other models such as Doubling-Adding method, Monte Carlo methods. Sensors: AIRS, AMSU, HIRS, and WINDSAT

Plans (cont.) Testing of the beta version CRTM will be completed at the end of September and the tested code will be provided to JCSDA. Continue to work with the community to integrate RT components. Conduct comparisons between CRTM calculations and observations (CloudSat CALIPSO, ARM, etc.)

Issues Layer to level profile conversion OPTRAN vs. OSS

Layer to level profile conversion The NWP system produces layer temperature profiles, but some RT components require level temperature profiles Possible solutions: (1) Assuming T layer (i) = 0.5*(T level (i-1) + T level (i)), with known Ts and {T layer (i), i=1, n}, solve the equation for {T level (i), i=0, n} (2) Predict {T level (i), i=0, n} from Ts and {T layer (i), i=1, n} using regression technique: y = Ax (3) Interpolation

Examples of layer to level temperature conversion Original level profile A layer profile is constructed from it: T_lay(i) = 0.5*(T_lev(i)+T_lev(i+1)) The difference between the original level profile and that retrieved from the layer profile by solving the equations. 0.5 k error is added to the surface air temperature. The difference between the original level profile and that by interpolating the layer profile on the level grids. 0.5 k error is added to the surface air temperature.

Comparison between OPTRAN and OSS Yong Han, Larry McMillin and Xiaozhen Xiong NOAA/NESDIS/ORA Jean-Luc Moncet, Gennadi Uymin and Sid Boukabara AER, Inc

Data sets for the comparisons UMBC 101 level 48 profile set UMBC 101 level 48 profile set ECMWF 101 level 52 profile set ECMWF 101 level 52 profile set For each set the following data are prepared: For each set the following data are prepared: –LBLRTM SRF-averaged gaseous transmittances for training OPTRAN –LBLRTM Monochromatic radiances for training OSS –Ground-truth channel radiances obtained by convolving LBLRTM monochromatic radiances with the SRFs Settings for the independent data set: Settings for the independent data set: –Specular surface is assumed: IR emissivity = 0.98; MW emissivity = 0.6 –Surface pressures are varied among different profiles Data are prepared (by AER, Inc) for the following sensors: Data are prepared (by AER, Inc) for the following sensors: AIRS_aqua, HIRS3_n17, AMSU_n17, SSMIS_f16 But results shown here only for AIRS, HIRS, AMSU and SSMIS

Problem in choosing a common training data set Initially we want to train and test OPTRAN and OSS with the same data sets, but unfortunately OPTRAN and OSS are sensitive to different issues and therefore have different requirements for the training data. OPTRAN is better trained with the UMBC set and OSS is better trained with five perturbations of the ECMWF set. Initially we want to train and test OPTRAN and OSS with the same data sets, but unfortunately OPTRAN and OSS are sensitive to different issues and therefore have different requirements for the training data. OPTRAN is better trained with the UMBC set and OSS is better trained with five perturbations of the ECMWF set.

RMS difference Mean difference OPTRAN vs. OSS at AMSU channels OSS Trained with ECMWF set Tested with UMBC set OPTRAN Trained with ECMWF set Tested with UMBC set

OPTRAN-V7 vs. OSS at AIRS channels OSS Trained with ECMWF set Tested with UMBC set OPTRAN Trained with UMBC set Tested with ECMWF set

Water vapor Jacobians at strong water vapor channels

Water vapor Jacobians at weak water vapor channels

Computation & Memory Efficiency OPTRAN-V7 Forward, Jacobian+Forward OPTRAN-comp Forward, Jacobian+Forward OSS Jacobian+Forward AIRS7m20s, 22m36s10m33s, 35m123m10s HIRS4s, 13s5s, 17s9s Time needed to process 48 profiles with 7 observation anglesOPTRAN-V7 single, double OPTRAN-comp double precision OSS Single precision AIRS 33, HIRS 0.26, Memory resource required (Megabytes)

Summary Radiance accuracy: Radiance accuracy: –Trained with the ECMWF data set (for a nominal accuracy = 0.05K) and tested with the UMBC set, OSS has an overall accuracy better than 0.05 K; trained with the UMBC data set and tested with the ECMWF data set, OPTRAN has an overall accuracy better than 0.1 K –A good OSS feature is that its radiance accuracy can always be improved by increasing the number of nodes. However, there is a trade-off between the accuracy and the computation and memory efficiencies. Jacobian accuracy: Jacobian accuracy: –Both OPTRAN and OSS provide accurate temperature Jacobians and Jacobians for strong absorbers –The OSS Jacobian model may perform poorly for weak absorbers due to the fact that OSS is trained in radiance space and the weak absorbers are weighted low under the training thresholds; OPTRAN can provide reasonable Jacobians for weak absorbers because OPTRAN is trained in transmittance space and errors for each gaseous components are minimized. Computation efficiency: Computation efficiency: OSS is significantly faster than OPTRAN Memory requirement: Memory requirement: –The amount of memory taken by OSS depends not only on the number of channels, but also on the degree of node overlap. For the sensors considered here, OSS takes significantly more memory than OPTRAN. –Compact OPTRAN is superior in memory use, taking only a small fraction of the amount of memory required by OSS and OPTRAN-V7.