1 / 32

Integrating Community RT Components into JCSDA CRTM

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

Télécharger la présentation

Integrating Community RT Components into JCSDA CRTM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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, 20-21 April 2005

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

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

  5. CRTM Components public interfaces CRTM Initialization Forward CRTM Jacobian CRTM CRTM Destruction Surface Emissivity/Reflectivity Model(s) Aerosol Absorption/Scattering Model Cloud Absorption/Scattering Model Gaseous Absorption Model RT Solution Source Functions

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

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

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

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

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

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

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

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

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

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

  16. RT Solutions (cont.) • UCLA vector d-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.

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

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

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

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

  21. Issues • Layer to level profile conversion • OPTRAN vs. OSS

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

  23. Examples of layer to level temperature conversion 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. Original level profile A layer profile is constructed from it: T_lay(i) = 0.5*(T_lev(i)+T_lev(i+1))

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

  25. Data sets for the comparisons • UMBC 101 level 48 profile set • ECMWF 101 level 52 profile set • 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: • 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: AIRS_aqua, HIRS3_n17, AMSU_n17, SSMIS_f16 But results shown here only for AIRS, HIRS, AMSU and SSMIS

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

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

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

  29. Water vapor Jacobians at strong water vapor channels

  30. Water vapor Jacobians at weak water vapor channels

  31. Computation & Memory Efficiency Time needed to process 48 profiles with 7 observation angles Memory resource required (Megabytes)

  32. Summary • 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: • 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: OSS is significantly faster than OPTRAN • 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.

More Related