bullet  EUMETSAT   bullet  SAFs   bullet   NWP SAF   bullet  Deliverables   bullet  RTTOV   bullet  RTTOV v7  bullet  Bugs

RTTOV v7 bugs

  1. There are some errors in the error return codes from RTTOV v7 as follows: Table 6 of the Users Guide should read: IFAIL = 27 indicates "Surface wind unphysical" and
    IFAIL = 26 indicates "Surface pressure unphysical". The surface temperature exceeding limits is set to 21 not 14 and 24 as given in Table 6.
  2. For some compilers RTTOVCLD does not like the cloud fraction profiles to be filled with the  value of 1.0. The output can be -nan. If this occurs suggest filling the cloud fraction profiles with values of 0.9999. 
  3. The fix to item 7 for RTTOV v7 (see RTTOV v7 original bug list below) was only provided for the forward code. This gave problems to AIRS radiance assimilation. All the routines have now been corrected and are avalable here (the calling routines also had to be modified). If you use the TL/AD/K codes you are advised to update the code with these modified routines.
  4. For some platforms (e.g. IBM) and compilers (e.g. xlf90) the reading of the ASCII coefficient files has a problem in that the carriage return at the end of a line is not correctly read. In this case replacing the offending character at the end of each line in the coefficient file with a blank character fixes the problem. 
  5. In prfin.f90 of RTTOV v7 a soft limit flag can overwrite a hard limit flag since the ierr variable is overwritten as one proceeds from jl=1,klenpf. Suggest that the code be corrected by allowing a soft overwrite only if a hard limit has not yet been detected in a given profile. Example of correction provided for water vapour check here which could be done for all other soft checks in prfin.f90.
  6. The routine RTTOVCLDK.f90 has a minor bug in that the output array ptbcld(knchpf) does not contain the output cloud affected brightness temperatures. A corrected routine is provided here.
  7. The dimensioning of the variable nlevfs is incorrect in two places for the _K routines. The corrected routines are available here.

The list below only refers to the RTTOV v7 original code distributed before Jan 2003. These have been fixed for RTTOV v71 distributed after Jan 2003.

  1. The profile limits in the RTTOV v7 coefficient files (beyond which the simulation will be less accurate) are wider than they should be. This was to maintain consistency with those limits in RTTOV v6 files. This has the result that you only get warning flags when the input profile is well outside the range and so it is possible to get profiles outside the valid range for which the coefficients were computed but still unflagged. To make use of better defined profile limits you can replace the limits in the coefficient files with the new limits available here. Just cut and paste in the new limits. The error flags should then be set for any profiles beyond the valid range. Note that the simulations are still reasonable within the wider profile limits but not as accurate as those within the narrower profile limits.
  2. In the description of routines RTTOV, RTTOVTL and RTTOVAD, the parameter IFAIL is said to have a dimension of JPPF. In the actual code itself, this parameter has the dimensions (KNPF,NJPNSAT). Therefore, when the user specifies a smaller dimension than that of the code it can cause memory problems. The second argument of the IFAIL flag is the sensor order as loaded up in RTTVI. So the first sensor you load up in RTTVI has the argument 1 the second sensor has 2 and so on. It is not the RTTOV id sensor number. The on-line documentation in the users guide and technical report has been corrected.
  3. When RTTOV v7 is called with more than 1 profile and there is a mix of surface types the FASTEM surface emissivity calculation only computes the ocean surface emissivity even though the surface type may be land.  This bug will not affect you if you only call RTTOV v7 with 1 profile per call.
  4. When using the FASTEM-2 option over land the PSSV(4) and PSSV(5) coefficients are zero for some of the surfaces (e.g. all summer cases), which in turn leads to a value of plandfastem(4,iprof) = 0.0 in subroutine EMISS.f90. This is then checked against equality to zero which stops the program. Corrected versions of the subroutines EMISS.f90 and EMISSTL.f90  for both items 3 and 4 can be downloaded by saving the links to them earlier in this sentence.
  5. The units of wmix and wmixs as given in the comments are often incorrectly stated as g/kg when they should be in ppmv. This can lead to confusion for users. Subroutines with incorrect comments are RTTOV/TL/AD/K, PRFIN/TL/AD/K, PRFTAU/TL/AD/K. Similarly the units of qmax and qmin in RTTVI and RTTOVCF should be ppmv. The code itself is correct.
  6. For SSMI(S) channels 22-24 FASTEM-1/2 does not compute a valid emissivity. As these channels do not see the surface it does not affect the simulations but a corrected version of EMISS.f90 can be downloaded.
  7. For AIRS simulations some bad optical depths can be computed for single layers which can slightly affect the computed brightness temperature. A modified version of OPDEP.f90 can be downloaded to correct for this. Other sensors appear to be unaffected.
  8. There is a bug in the subroutine PRFIN, line 225: The array ierr is accessed with indices j and ksat. The variable j is used in the previous loop (starting line 206) as counter. This previous loop is left with j = knpf +1, while the first dimension of ierr is knpf. The effect of this is if you input a profile with pressure levels which do not match those in the RT coeff file the program aborts at this point in the code rather than returning in a controlled manner with ierr set to 20. Updated versions of the modified code to correct this bug are PRFIN.f90 and RTTOV.f90 which can be downloaded.
  9. If you use the RTTOVK code note it is important to always initialise the array RADOV (last argument) before calling RTTOVK.
  10. When fractional cloud cover is set > 0. in array PCV(2,iprof) there is an error in the RTTOVK output in the K of the PCV array. The error is in RTINTK.f90 and you can download a corrected version of this routine. Note the RTTOVCLDK routines are not affected by this bug as this parameter is not used.