SYN1deg cloud locations/timing

Use this Forum to find information on, or ask a question about, NASA Earth Science data.
Post Reply
kresmoi
Posts: 2
Joined: Wed Oct 12, 2022 10:59 am America/New_York
Answers: 0

SYN1deg cloud locations/timing

by kresmoi » Wed Oct 12, 2022 1:19 pm America/New_York

Hello,

I've noticed the SYN1deg-hourly RSR values do not always match where I (naively) expect high values to be for a given hourbox based on where reflective clouds are visible in a geostationary image. I expect hourbox-averaged geostionary radiances to align well when downscaled into the 1x1 degree equal-area gridboxes in the domain of each geostationary satellite. In one scene I'm looking at under the GOES-16 domain for example the Syn1deg-hourly RSR values appear to be time-shifted earlier in time than what an equally weighted average of the GOES-16 radiances in the hourbox would suggest (that is, following the cloud motion backwards-in-time by eye can predict where the mismatched high-RSR values will appear compared with the averaged GOES-16 radiances that show reflective clouds).

I'm under the impression there may be two causes for this:
1) some of the cloud locations are derived from low-earth orbit sensors, which may be overpassing at a different time than the 30-minute mark in the hourbox.
2) RSR may not be an equal-time-weighted average in the hourbox (I am suspicious because of this sentence in the Data Quality summary for Edition4A: "The corresponding
midpoint is 0.5 GMT, except for SW fluxes, where the integrated cosine of the solar zenith
angle is considered the midpoint of the hour box in order to facilitate the hour box averaging
as described in the previous bullet.")

In case #1, is there metadata provided in the HDF files that indicates which gridboxes are informed by low-earth-orbit sensors and which are informed by geostationary radiances? If not, do you have any recommendations on the easiest way to calculate this?

In case #2, can anyone please clarify this sentence for me? Does it mean that the geostationary radiances used as input for the RSR calculation are time-weighted when they are averaged in the hourbox, via the cos of SZA? If not then what does it mean?

And finally, if there's other possible explanations for high-RSR pixels to be shifted by a gridbox (or two) compared with the geostationary radiances, please let me know.

Thanks for any help,
-Kevin

Tags:

ASDC - ingridgs
Subject Matter Expert
Subject Matter Expert
Posts: 142
Joined: Fri Apr 23, 2021 9:14 am America/New_York
Answers: 1
Has thanked: 17 times
Been thanked: 7 times

Re: SYN1deg cloud locations/timing

by ASDC - ingridgs » Fri Oct 14, 2022 2:39 pm America/New_York

Thank you for your question.

A Subject Matter Expert has been notified and will answer your question shortly.

Please stand by!

wfmiller
Subject Matter Expert
Subject Matter Expert
Posts: 19
Joined: Tue Nov 26, 2019 3:58 pm America/New_York
Answers: 0
Location: Langley Research Center
Been thanked: 2 times
Contact:

Re: SYN1deg cloud locations/timing

by wfmiller » Wed Oct 19, 2022 11:20 am America/New_York

For GOES, the 0.5 GMT image (30 minutes after) for each GMT hour increment is used (for example 0 to 1 GMT, 1-2 GMT, etc). The four 15 minute images for an hour are not averaged.

A 6-km subset of the GOES-16 native resolution imagery is used.

If a MODIS swath occurs for that GMT hour, then the MODIS channel radiances and clouds replace the GOES-16 observations.
The time of the MODIS swath is not set for the region.

The SYN1deg-hour has either # of CERES SW observations the top row, and # of GEO SW observations bottom row (Cyan is one and pink is 0). This is how to differentiate between CERES or GEO input.
SYN1deg_SWObs_Count_Example.jpg
SYN1deg_SWObs_Count_Example.jpg (77.92 KiB) Not viewed yet

The HDF SYN1deg-1Hour names for the above variables are:
num_sw_obs – is 1 when a CERES observation was used, 0 If not
num_geo_sw_obs – is 1 when a Geostationary observation was used, 0 if not

The CERES observation takes precedence within a grid box. Neither CERES or GEO observation may be available for a grid box or its night, then both variables would be 0. The flux for that hour would then be interpolated in time from available observations.

The GOES or MODIS observation is time shifted to the integrated solar zenith angle (SZA) for the GMT hour increment. This is simply a cos(SZA) ratio for the conversion

If a front is passing by a region during the same GMT hour interval can have dramatic changes in the channel radiances.

Obtaining RSR from times with GEO observation is involved which might account for some of the discrepancy. The GEO narrow band radiance is converted to an albedo which is then converted to a broadband albedo. This albedo is than converted to a flux by multiplying it by the incoming solar flux integrated over the hour. Noise in the NB to BB conversion and maybe higher solar zenith angle at earlier grid box might result in a higher flux with the same albedo.

If this doesn't address your concern, please provide the date and time and area of you concern.

kresmoi
Posts: 2
Joined: Wed Oct 12, 2022 10:59 am America/New_York
Answers: 0

Re: SYN1deg cloud locations/timing

by kresmoi » Thu Oct 20, 2022 8:30 am America/New_York

Thank you for the information! This clarifies a lot for me.

I have some remaining confusion though. From inspection of the num_geo_sw_obs and num_sw_obs fields in the HDF files, it appears there are constraints on what is considered a valid geostationary observation within the hourbox that I wasn't aware of. Anecdotally, the solar zenith angle looks like it must be less than 60-65 degrees (but it is not a precise match for any given SZA threshold I can try). Near the geostationary domain bisection points (eg between GOES-16 and MSG) there are small peaks where num_geo_sw_obs are missing, so it also appears there is a limit of how large the geostationary viewing angles can be. Sunglint regions appear to be omitted, and there are also sprinkles of gridboxes in other places for which I'm unclear on why they are not counted as a valid num_geo_sw_obs (they look too frequent to be geostationary data quality issues, but perhaps it is so).

Please find attached an example image where I plotted the SYN1deg RSR and overlaid on top of it a mask of where neither num_geo_sw_obs nor num_sw_obs is true but there is some nonzero RSR. It contains examples of all these speculated validity constraints and is from 2018-01-01 at 04:30 UTC.

Can you point me to where I can find documentation on the full set of conditions that are required for the in-hourbox geostationary observations to be used, other than "CERES overpass did not provide an observation" ?

I have looked through "Geostationary Enhanced Temporal Interpolation for CERES Flux Products" and "Advances in Geostationary-Derived Longwave Fluxes for the CERES Synoptic
(SYN1deg) Product" and the "CERES_SYN1deg_Ed4A Data Quality Summary (4/8/2021)" but I don't see any mention of a cutoff of SZA by ~65 degrees, etc. My apologies if I missed it.


-Kevin
Attachments
example_20180101_0430.png
example_20180101_0430.png (288.91 KiB) Not viewed yet

wfmiller
Subject Matter Expert
Subject Matter Expert
Posts: 19
Joined: Tue Nov 26, 2019 3:58 pm America/New_York
Answers: 0
Location: Langley Research Center
Been thanked: 2 times
Contact:

Re: SYN1deg cloud locations/timing

by wfmiller » Wed Oct 26, 2022 2:45 pm America/New_York

SW flux narrowband to broadband conversions are used in the SYN1deg.

There is also a solar zenith cutoff of 60 degrees for the SW flux narrowband to broadband conversions being performed, but this does not impact the cloud properties.

Where sun glint is identified in the GEO observations, the clouds and calculated SW fluxes are not used. There would be glint areas in each of the 5 GEOs used.

A combination of automated and manual quality checks are performed on the GEO images. Scan lines or partial scan lines that seem non-physical are removed. The number of scan lines removed increase near equinox for the satellite. Additionally, missing imager radiances would not be used.

If the SW fluxes are not used then temporal interpolation between the previous and following hour GEO or CERES regional SW fluxes are used to estimate the SW flux. Interpolation is also applied to fill any missing cloud properties.

The GEO quality issue is a result of GOES second generation had an interesting scan patterns, Full Disk (FD) every 3-hour (not the same time for GOES East or West), with separate Northern and Southern Hemisphere scans that needed to be stitched together for the remaining hours. I have enclosed a plot of the VZA limitations, the GMT to see how the GOES scans are stitched together to have a complete GEO domain image.

The individual GEO satellite hourly netCDF files containing the pixel channel radiances and cloud properties can be downloaded here (https://search.earthdata.nasa.gov/search/granules?p=C1584977034-LARC_ASDC, https://search.earthdata.nasa.gov/search/granules?p=C1584977035-LARC_ASDC).

Longitudinal boundaries are used between each GEO satellite depending on satellite position and data quality. Since the GEO over the Indian Ocean had the fewest channels for the longest time, its extent is the smallest.

The above implementation details are not captured in any public documents.

To be more helpful please provide what you are trying to use the data for, the application (for example temporal resolutions, what parameters are key)
Top image is the GMT time for the GEO observations used between 1 and 2 GMT. The middle image is the GEO view zenith angle. The bottom image is the satellite ID of the GEO used.
Top image is the GMT time for the GEO observations used between 1 and 2 GMT. The middle image is the GEO view zenith angle. The bottom image is the satellite ID of the GEO used.
SYN1deg_GEO_Info.jpg (119.75 KiB) Not viewed yet

Post Reply