Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

ERROR with CRTM_K_Matrix

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.


Dear Colleges,

I am failing to assimilate the AMSU-A radiance data.

Could you please look the errors in my log.wrfda file and check my namelist.input file to identify the problem(s)?
You can see from my log.wrfda file that 595 radiance observations are available over my simulation domain.
I am using WRFDA v4.0.

It seems my errors are related to the crtm_coeffs files, but I uploaded those from as recommended.

In my simulations I use the LU_INDEX/LANDUSEF fields interpolated from 21-class MODIS.

I would much appreciate more helpful comments on my namelist file to improve the radiance data assimilation.



  • namelist.input.txt
    1.7 KB · Views: 111
  • log.wrfda.txt
    7.2 KB · Views: 110
This looks like related to your use of 21-class MODIS Landuse.
WRFDA may need some code update to use it. Did you try the older one like USGS?
Dear Jake,

Thanks for your reply! Indeed, I also suspected that the use of 21-class MODIS Landuse could be the reason for this issue. However, my experience with the WRF simulations over our region shows that it is better to use 21-class MODIS Landuse rather than the USGS. On the other hand, the older version of WRFDA (Versions 3.8.1) successfully assimilated satellite radiance with 21-class MODIS Landuse.
Could this issue be solved without changing the landuse scheme?

Dear Artur,

Have you tried using the WRF/WRFDA code in the develop branch on github ( WRFDA V4.0 still uses CRTM v2.2.3. It looks like you are using CRTM coefficient files for CRTM V2.3.0. The latest WRFDA code about to be released, and available in that develop branch, is compatible with CRTM V2.3.0. You could try the soon to be released version 4.1 branch instead (, which may be more stable.

EDIT: Although looking at the CRTM code itself, the problem appears to be with the Land_Type used as input to CRTM. The error you report is only given when Land_Type (derived from IVGTYP in the fg file) is set to 0 in the nearest grid cell to a particular pixel. Therefore does your fg file have any zeros in IVGTYP?


Thanks for your reply and help!
You are right I edited my Registry.EM_COMMON file trying to reduce the wrfout* files size (, I also excluded the IVGTYP parameter. I will recompile the WRF model with the default Registry.EM_COMMON file and try again to assimilate satellite radiance.


I have the same issue but now with assimilation of HIRS4, NOAA 18 data.

I have already updated the WRFDA version to v4.1 and I am using the CRTM V2.3.0 as you recommended. Now, I have all default fields in my "fg" file as I mentioned in my previous post (the file is attached). However, the error message is the following:

---------------------------- FATAL ERROR -----------------------
Fatal error in file: LINE: 210
modify crtm_irland_coef to use the coef file that is consistent with your model land use type
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
STOP wrf_abort

You can find attached the entire information of WRFDA run in log.out file. The hirs4.bufr, LANDUSE.TBL and namelist.input files are also attached.

I think I need to make some modifications in the file. I am not sure, but it seems that this issue is due to use of Modis landuse instead of USGS.
Could you help me?



  • log.out.txt
    6.5 KB · Views: 95
  • fg.tar.gz
    91.2 MB · Views: 96
  • hirs4.tar.gz
    24.7 MB · Views: 92
  • namelist.input.txt
    1.9 KB · Views: 107
    29.1 KB · Views: 94
Which coefficient file are you using for IR over land in CRTM? This should be linked/copied into your run directory. The landuse categories associated with that file need to match with the num_land_cat setting in the namelist and with the fg file (and corresponding met_em* files from WPS).

WPS namelist:
geog_data_res = 'usgs_30s+default','usgs_30s+default',

WRF namelist:
num_land_cat = 24

CRTM file:


WPS namelist:
geog_data_res = 'default','default',

WRF namelist:
num_land_cat = 21

CRTM file:
I forgot to mention that the namelist option "crtm_irland_coef" also needs to match the coefficient file you are using. That appears to be the cause for your error.

I am also facing the same "CRTM_K_Matrix(FAILURE) : Input data check failed for profile #1" issue. The error massage is:

CRTM_LandSurface_IsValid(INFORMATION) : Invalid Land Surface data
CRTM_K_Matrix(FAILURE) : Input data check failed for profile #1
---------------------------- FATAL ERROR -----------------------
Fatal error in file: <A HREF=""></a> LINE: 38
Error in calling CRTM_K_Matrix

I have assimilated AMSUA data successfully. But when I tried to assimilate MHS data I got the said issue. I have tried with both USGS and IGBP Landuse data. However, the errors are same. I am using CRTM_2.1.3 available with WRFDA_V3.8. I have attached the namelist and log files for your reference. Kindly help me to solve the issue.


  • log.txt
    10.8 KB · Views: 105
  • namelist.input_wrfda.txt
    5.2 KB · Views: 110
As of now , there is no reply. I hope somebody will help me. I have further checked and found that the error that I have mentioned in my previous post is with only NOAA-19 whether its is MHS or AMSUA, it really doesn't matter.

The following record is not present in your namelist.input file:



If you are using MODIS landuse in your WRF simulations, add this in your namelist and try to run again.
Thank you for your reply. I have tried with both MODIS and USGS LULC data. As per your suggestion, I have put the line in my namelist file and run again. However, the error is the same. I could run for NOAA-15-18 successfully for both AMSU and MHS. But the error I got is only with NOAA-19. Whenever I tried to use options such as (1-19-3, 1-19-15), the error arises.
Please consider the following lines in var/external/crtm_2.3.0/libsrc/CRTM_Surface_Define.f90:

    IF ( Sfc%Land_Temperature      < ZERO .OR. &
         Sfc%Soil_Moisture_Content < ZERO .OR. &
         Sfc%Canopy_Water_Content  < ZERO .OR. &
         Sfc%Vegetation_Fraction   < ZERO .OR. &
         Sfc%Soil_Temperature      < ZERO .OR. &
         Sfc%LAI                   < ZERO      ) THEN
      msg = 'Invalid Land Surface data'
      CALL Display_Message( ROUTINE_NAME, TRIM(msg), INFORMATION )
      IsValid = .FALSE.

This is a slightly different error than the one described above, which was caused by the land type only. Here there are several possibilities. All of these quantities are set in var/da/da_radiance/, and can then be traced back to WRF variables stored in the "grid" as described in the Registry directory. These need to be checked one-by-one to determine the cause of the error.
WRFDA only handles the land type conversion from WRF to CRTM for
num_land_cat=24 (USGS no lake) and
num_land_cat=20 (MODIS no lake)