Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent units of geostationary radiances #414

Closed
sfinkens opened this issue Sep 13, 2018 · 4 comments
Closed

Inconsistent units of geostationary radiances #414

sfinkens opened this issue Sep 13, 2018 · 4 comments

Comments

@sfinkens
Copy link
Member

Describe the bug
Units and standard names of GOES-16, MSG-4 and Himawari-8 radiances seem to be inconsistent with the YAML definitions. The YAML definitions indicate units W m-2 um-1 sr-1 and standard name toa_outgoing_radiance_per_unit_wavelength for all imagers. However, GOES-16 radiances are in mW m-2 sr-1 (cm-1)-1 (standard name toa_outgoing_radiance_per_unit_wavenumber). MSG-4 radiances seem to be in mW m-2 cm-1 sr-1 (factor 10^7). Himawari-8 radiances are smaller than GOES/MSG by a factor of 10, not sure what unit that is.

For GOES-16 scene['C14'].attrs['units'] is correct though. Probably the attribute is overwritten with the value from the netCDF file.

To Reproduce
I compared ~10um IR images at ~09:00 local time (00 UTC for Himawari-8, 09 UTC for MSG-4, 14 UTC for GOES-16).

from satpy import Scene
import glob
import matplotlib.pyplot as plt


# GOES 16
filenames = ['OR_ABI-L1b-RadF-M3C14_G16_s20182481400355_e20182481411122_c20182481411188.nc']
g16_channel = 'C14'
g16_scene = Scene(filenames=filenames, reader='abi_l1b')
g16_scene.load([g16_channel], calibration='radiance')

# Himawari 8
filenames = glob.glob('HS_H08_20180905_0000*')
h8_channel = 'B13'
h8_scene = Scene(filenames=filenames, reader='ahi_hsd')
h8_scene.load([h8_channel], calibration='radiance')

# MSG 4
filenames = glob.glob('H*0900-__')
msg4_channel = 'IR_108'
msg4_scene = Scene(filenames=filenames, reader='hrit_msg')
msg4_scene.load([msg4_channel], calibration='radiance')

print 'GOES-16', g16_scene[g16_channel].max().values, g16_scene[g16_channel].attrs['units']
print 'Himawari-8', h8_scene[h8_channel].max().values, h8_scene[h8_channel].attrs['units']
print 'MSG-4', msg4_scene[msg4_channel].max().values, msg4_scene[msg4_channel].attrs['units']

plt.figure()
plt.imshow(g16_scene[g16_channel])
plt.colorbar()
plt.title('GOES-16')

plt.figure()
plt.imshow(h8_scene[h8_channel])
plt.colorbar()
plt.title('Himawari-8')

plt.figure()
plt.imshow(msg4_scene[msg4_channel])
plt.colorbar()
plt.title('MSG-4')

plt.show()

Output:

GOES-16 150.17288146540523 mW m-2 sr-1 (cm-1)-1
Himawari-8 11.933104 W m-2 um-1 sr-1
MSG-4 159.7228 W m-2 um-1 sr-1

Environment Info:

  • OS: Linux
  • SatPy Version: 0.10.0a0.dev0
  • PyResample Version: 1.10.2a0.dev0
@sfinkens
Copy link
Member Author

Wait, if GOES-16 radiances are given per unit wavenumber, shouldn't they be a factor of 2*pi larger than those per unit wavelength?

@djhoese
Copy link
Member

djhoese commented Sep 13, 2018

I don't usually deal with radiances directly and not sure I understand what the units physically mean so I'm not sure I can help that much. However, if a reader has units specified in the YAML file and the resulting band has different units then that is a bug. As @mraspaud mentioned on slack we tend to use the units provided in the raw file.

In the past we tried harder to standardize the units between readers, but realized that the better answer may be to have the arrays convert to other units more easily by the person/code using it. This is something that the xarray/metpy/unyt communities are working on. Right now satpy only really prefers that reflectance data be in % (0-120ish) and brightness temperature data be in K.

@mraspaud
Copy link
Member

So what is the status on this issue ?

@sfinkens
Copy link
Member Author

I'm going to lookup the radiance units in the documentation and then update the YAML files if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants