The local attributes "scale_factor" and "add_offset," attached to each and every SDS as local attributes, are used for the conversion of stored (packed) SDS integer data to geophysical floating point numbers. The formula to descale the data follows conventional HDF usage:

It is probably confusing to most users that the HDF convention calls the offset "add_offset" even though it's subtracted from the stored integer when unpacking the data. It seems likely that this terminology originated from the programmer's, and not the end user's, perspective, since to pack the data the offset is added.

The units of the unpacked geophysical floating point value are indicated by the "units" local attribute that is also provided with each SDS.

The "valid_range" local attribute applies to the packed data (before de-scaling). The two valid range values given are the expected low and high values of valid (non-fill) packed data. Note that no valid range screening on the input L2 data or the output L3 data is performed. The reason for this is sometimes absolute valid ranges are difficult to determine in advance and the algorithm developers wanted to avoid the potential loss of good data. Therefore users should not be surprised to find non-fill data points that fall outside the documented valid range; however it should raise a flag for the user to make sure they are reading the data correctly.

Users should note that they can also find the scaling, units, and valid_range factors within the File Specification located on this web site. Just search the file spec for the SDS you are interested in, and all local attributes will be listed underneath the SDS under review.


How do the cloud mask and optical properties 'cloud fractions' differ?

The Level-3 (L3) cloud fraction that garners the most interest from MODIS data users is cloud fraction derived directly from the 35_L2 Cloud Mask. These L3 cloud mask cloud fraction SDSs have the prefix Cloud_Fraction, Cloud_Fraction_Day, & Cloud_Fraction_Night. The Level-2 (L2) cloud mask cloud fraction, which L3 uses to compute statistics, is calculated in the cloud top properties algorithm and stored in the 06_L2 HDF file. The L2 cloud mask cloud fraction is derived in L2 (the L2 SDS names are identical to those shown above) by reading the 1 x 1 km Cloud Mask "Cloudiness Probability Flags" (QA Plan for details). The Cloud Mask Cloudiness Flag can have the following settings: 0 = confident cloudy, 1 = probably cloudy, 2 = probably clear, and 3 = confident clear. In the computation of the L2 cloud mask cloud fraction, the first two flags are assigned 100% cloudy and the last two flags 100% clear in the computation. Then in each 5 x 5 km L2 retrieval box, the average L2 cloudiness is computed by computing the fraction of the 1-km pixels that are cloudy. In the L3 Daily product, the cloud mask cloud fraction is computed by taking an unweighted average of these 5 x 5 km L2 cloud fractions in each 1° x 1° L3 grid box.

The second most utilized L3 cloud fraction is that derived from the Cloud Optical Properties retrieval. All optical property cloud fractions are computed for daytime scenes only (solar zenith angle less than 81.4°). These L3 cloud optical properties cloud fraction SDSs have the prefix Cloud_Fraction_Combined, Cloud_Fraction_Liquid, Cloud_Fraction_Ice, & Cloud_Fraction_Undetermined. The first parameter represents the cloud fraction for all cloud phases; the second, liquid water clouds only; the third, ice clouds only; and the forth, undetermined cloud phase clouds only. Every sampled L2 grid point that has a Primary Cloud Retrieval Outcome Flag = 1 (Retrieval Successful) and a Primary Cloud Retrieval Phase Flag of 2 (Liquid Water Cloud), 3 (Ice Cloud), or 4 (Undetermined Phase Cloud) are taken as 100% cloudy for the cloud phase category in question. These additional flags are part of the QA Flag family detailed in the QA Plan.

Finally, one should remember that the L3 Cloud Optical Property Cloud Fraction is computed from sampled L2 cloudiness at 5-km resolution in the 1° x 1° L3 grid box; while the Cloud Mask Cloud Fraction is computed in the 1° x 1° L3 grid box from average cloud fractions in the 5 x 5 km region (not sampled at L3). Although it is not believed this sampling vs. averaging difference has a serious impact on the final results, users should be aware that the two cloud fractions are computed differently. Since the cloud optical properties cloud fraction uses the cloud mask cloud fraction as input, one would think the former would always be smaller than the latter -- however sampling can lead to a small number of L3 1° grid cells where this expected relationship does not hold true.

The primary benefits to the cloud optical properties cloud fraction is it allows an analysis of the cloud fractions separated by cloud phase (liquid water clouds vs. ice clouds). The primary benefits to the cloud mask cloud fraction is it's the most direct way to view cloud mask results; and has cloud fraction results at night.


What do the 'undetermined' and 'combined' cloud phases mean?

The undetermined cloud phase means the cloud optical properties retrieval algorithm could not make a determination of the cloud phase (liquid water or ice). This may have been caused by viewing anomalies in the retrieval (sunglint), contamination of the scene by aerosol, or a multi-layer cloud with mixed phases (e.g., thin cirrus overlying liquid water clouds). For these undetermined retrievals the liquid water libraries are used in the cloud optical properties retrievals, but the retrievals are considered to be of lower confidence (and quality) than those that are placed in one of the other primary phase categories.

The combined phase is simply a combination of all cloud phase categories: liquid water, ice, and undetermined.


What is the minimum illumination requirement for a MODIS retrieval?

Many MODIS parameters produce results for both daytime and nighttime retrievals; so for those there is no minimum illumination requirement. MODIS parameters that are earmarked "Daytime Only" are (i) Aerosol, (ii) Near-Infrared Water Vapor, (iii) Cirrus Detection, and (iv) Cloud Optical Properties. For these daytime only parameters, the Aerosol retrieval requires the solar zenith angle to be less than 72°, all others require the solar zenith angle to be less than 81.4° (which matches the cloud mask classification of "daytime").


How should the various multilayer cloud fractions be interpreted?

There are a number of multilayer cloud fractions that use the "Multilayer Cloud and Phase Flag" to compute various cloud fractions. (See QA Plan for details on all flags used.)

The Cloud_Fraction_1L_(phase) parameter is computed the same way as the Cloud_Fraction_(phase) parameter, outlined above, except that it uses the "Primary Cloud Retrieval Multilayer Cloud & Phase Flag" where the flag is set to "single layer cloud." This gives the cloud fraction separated by phase for single layer clouds only.

The Cloud_Fraction_ML_(phase) parameter is computed the same way, except that it uses the "Primary Cloud Retrieval Multilayer Cloud & Phase Flag," where the flag is set to "multi-layer cloud." This gives the cloud fraction separated by phase for multi-layer clouds only.

Both of the cloud fraction parameters outlined above are true cloud fractions whose computation includes clear-sky pixel counts in the denominator. It is typical for the multi-layer liquid water cloud fraction to be less than the single-layer liquid water cloud fraction. For a particular cloud phase (liquid water or ice), when the two cloud fractions (1L and ML) are added, it will equal the standard Cloud_Fraction_(phase) SDS, which depicts cloud fraction for all layer clouds of that particular phase.

Finally there are a set of cloud "fractions" that do not include clear-sky pixel counts in the denominator; that is they are not standard cloud fractions but instead cloud ratios. SDSs that have the prefix "ML_Fraction_(phase)" show a ratio of multi-layer clouds to all-layer clouds for various cloud phases. In other words, it shows the percentage of clouds that were detected as multi-layer for various cloud phases.

Users should be aware that there are SDS name length limits; sometimes an SDS name might not be descriptive enough to determine its content. If at any time MODIS data users need more clarity on what any SDS actually contains, additional documentation as well as computational details can often be obtained from the local attribute "long_name" attached to each SDS. These attributes can also be found in the online version of the File Specification.


Is there a minimum L2 pixel count requirement to compute L3 statistics?

Within the L3 Daily product file, for any given 1° x 1° grid cell, only a single L2 non-fill pixel is needed to create L3 daily statistics. This tends to cause an artificial spatial expansion of sparce L2 data when going to a L3 global projection. For example, a sizable region might have only a few scattered L2 retrievals, but L3 might show solid coverage of 1° x 1° statistics.

MODIS L3 data users have a relatively easy way to monitor the number of L2 pixels that went into L3 statistics for each 1° x 1° grid cell. Pixel count data are stored within the L3 Daily product file in either the "Pixel_Counts" or the 4th dimension of the "Confidence_Histogram" SDS.

Likewise for the L3 Multiday product files, for any given 1° x 1° grid cell, only a non-fill daily grid cell for a single day is needed to create L3 multiday statistics. The only exception to this multiday statistic computation rule is in L3 products derived from L2 Aerosol parameters. The Aerosol group requested a special weighting scheme for L3 Multiday products, where a daily grid cell must have a pixel count of at least 6 to be included in the multiday statistic computation (See Table 4 in Section 4.2.) This was done because the Aerosol group felt that low pixel count daily grid cells were not very reliable and should be thrown out. This screening procedure also helped to reduce the number of low confidence multiday statistic grid cells near the poleward boundary (terminator) of their retrieval algorithm.


Are statistics within a L3 Daily file a single orbit snapshot or a multiple orbit average?

Two EOS satellites, Terra and Aqua, both carrying the MODIS sensor, are in sun-synchronous orbits. The Terra overpass time is around 1030 local solar time at the equator in its descending (daytime) mode and 2230 local solar time in its ascending (nighttime) mode. The Aqua overpass time is around 1330 local solar time at the equator in ascending (daytime) mode and 0130 local solar time in descending (nighttime) mode.

L3 SDSs within either a Terra or Aqua Daily file are made up of L2 data that are collected for daytime only, nighttime only, or combined daytime and nighttime scenes. Only L3 Daily SDSs that are based on L2 data collected for daytime only or nighttime only scenes, have the chance (depending on global location) to be pinned down to an approximate local solar time. MODIS L3 SDSs that are based on L2 data collected for combined daytime and nighttime scenes are, for most regions of the globe, a mixture of at least two MODIS overpasses approximately 12 hours apart.

To determine if a L3 SDS contains daytime data only, nighttime data only, or combined daytime and nighttime data, one needs to query the local attribute "Included_Nighttime_Data." If this attribute is set to "False," then it's a daytime only parameter (SDS). If this attribute is set to "True," then it's combined daytime and nighttime; unless the string "_Night_" appears somewhere in the SDS name, in which case it's a nighttime only parameter. It should be noted that this last nighttime-only case is of low incidence, only occurring in a few cloud top property derived parameters.

Due to overlapping orbits toward the poles, only the daytime only or nighttime only Daily SDSs from approximately 23°N to 23°S can be pinned down to an approximate local solar time (since they are made up of observations from a single MODIS overpass only). Poleward of 23°, L3 Daily data become an average of several overlapping orbits approximately 100 minutes apart. The marked increase in pixel counts towards the pole is due to overlapping orbits causing the L3 data to become a multiple orbit average, over mid-latitudes the pattern of pixel counts is typical for a single orbit snapshot that can be assigned a single (approximate) local solar time.

So in summary, to pin down a L3 Daily SDS to an approximate local solar time, it must be (i) either daytime only or nighttime only and (ii) constrained to L3 grid cells between approximately 23°N and 23°S latitude. Only in both these situations does any Daily SDS contain data from a single MODIS overpass, whose approximate local solar time is given above.

Users should note that for Collection 006 (expected to begin processing in 2012), we are examining the possibility of constraining overlapping data so L3 products contain data from fewer overlapping orbits (closer to a nominal local solar time).