List the steps someone needs to take to reproduce the bug.
Use convert_goes_ABI_L1b.f90 to generate obs_seq.out file for GOES AB1 16 radiance satellite data.
What was the expected outcome?
That the code would assign the appropriate IR channel (1-16) to the obs_seq file, such that the forward operator (RTTOV) can use the appropriate calculation to obtain the expected radiance for that channel (band wavelength)
What actually happened?
The obs converter offsets the channel (band_id) by 6. Thus channel 8 (for example) is encoded in obs_seq file as channel 2. This causes RTTOV to calculate the radiance for a completely different and incorrect waveband (0.64 micron instead of 6.2 micron for channel 2 and 8 respectively).
Error Message
Doesn't provide an error message because Channel 2 is still a viable wavelength. The result is that this gives incorrect expected prior observations from RTTOV. In this case, RTTOV returned a radiance of 0, because Channel 2 is a visible wavelength which cannot be generated from atmospheric emission (with namelist value addsolar = .false.) --- only from reflected solar. Channel 8 is an IR wavelength sensitive to upper atmosphere water vapor.
Which model(s) are you working with?
WRF4.4
Version of DART
latest
Have you modified the DART code?
No -- but fix is simple, just remove offset in obs converter. We also need to improve RTTOV documentation such that users check their rttov_sensor_db.csv, as well as their rtcoef (coefficent) files to makes sure the wavelength matches correctly. It is easy to have mismatching wavebands depending on the rtceof file used, can be UV/IR/NIR/VIS or IR only , which changes the number of wavebands.
Build information
Please describe:
Derecho using intel with RTTOV libraries.
hkershaw-brown
commented
1 month ago
Describe the bug
List the steps someone needs to take to reproduce the bug.
Use
convert_goes_ABI_L1b.f90to generate obs_seq.out file for GOES AB1 16 radiance satellite data.What was the expected outcome? That the code would assign the appropriate IR channel (1-16) to the obs_seq file, such that the forward operator (RTTOV) can use the appropriate calculation to obtain the expected radiance for that channel (band wavelength)
What actually happened?
The obs converter offsets the channel (band_id) by 6. Thus channel 8 (for example) is encoded in obs_seq file as channel 2. This causes RTTOV to calculate the radiance for a completely different and incorrect waveband (0.64 micron instead of 6.2 micron for channel 2 and 8 respectively).
Error Message
Doesn't provide an error message because Channel 2 is still a viable wavelength. The result is that this gives incorrect expected prior observations from RTTOV. In this case, RTTOV returned a radiance of 0, because Channel 2 is a visible wavelength which cannot be generated from atmospheric emission (with namelist value addsolar = .false.) --- only from reflected solar. Channel 8 is an IR wavelength sensitive to upper atmosphere water vapor.
Which model(s) are you working with?
WRF4.4
Version of DART
latest
Have you modified the DART code?
No -- but fix is simple, just remove offset in obs converter. We also need to improve RTTOV documentation such that users check their
rttov_sensor_db.csv, as well as theirrtcoef(coefficent) files to makes sure the wavelength matches correctly. It is easy to have mismatching wavebands depending on thertceoffile used, can be UV/IR/NIR/VIS or IR only , which changes the number of wavebands.Build information
Please describe:
Derecho using intel with RTTOV libraries.