Frequently Asked Questions

Q: Is there a minimum Level-2 (L2) pixel count requirement to compute Level-3 (L3) statistics? 

A: For the L3 daily products, only a single non-fill L2 pixel is needed within any given 1°×1° grid cell to create L3 daily statistics. This tends to cause an artificial spatial expansion of sparce L2 data when aggregating to L3. For example, a sizable region having only a few scattered L2 retrievals will have solid coverage of the 1°×1° grid cell statistics. Users, however, can query the Pixel_Counts SDSs to monitor the number of L2 pixels that went into L3 statistics for each 1°×1° grid cell. Likewise for the L3 multi-day products, only a non-fill daily grid cell for a single day is needed to create L3 multi-day statistics. An exception to this latter rule was instituted in Collection 6.1 (061) in all Aerosol related SDS's in the Monthly (M3) Product, where a new minimum count of 3 days was implemented. This Collection 6.1 change was implemented to reduce the impact of cloud, ice and snow contamination in Aerosol related SDS's in the heavily used Monthly (M3) product.

Q: Are statistics within a Level-3 (L3) Daily file a single orbit or a multiple orbit average?

A: All daily L3 SDSs for each grid cell include all daytime only, nighttime only, or combined daytime+nighttime L2 data pixels that fall within that grid cell on that date. Thus even the daytime and nighttime only SDSs may contain observations from multiple Terra or Aqua overpasses (approximately 100 minutes apart), with the exception of grid cells in the tropics, or roughly between 23°N and 23°S latitude, where orbit gaps exist because the MODIS swath is insufficiently wide to overlap with the previous overpass.

Q: Which daytime cloud fraction is best to use? 

A: There is no correct answer to this question. It is important to note, however, that the MOD35 cloud mask by design attempts to determine the likelihood of an obstructed field of view and will err on the side of “cloudy” when in doubt. As such, scenes with heavy aerosol loading (e.g., thick smoke or lofted dust), and despite best efforts scenes with exceptionally strong sunglint, can yield “not clear” designations by MOD35 that are otherwise considered “cloudy” in MOD06 and are problematic for cloud optical property retrievals. Starting in Collection 5, and continuing in Collection 6, a Clear Sky Restoral (CSR) algorithm (see Section 2.8 of the MOD06 User Guide) is implemented within MOD06 to “restore to clear” pixels that are thought to be not cloudy, as well as to identify two categories of pixels that are likely only partly cloudy (PCL) and are expected to be inappropriate for 1-D optical retrievals. Moreover, in Collection 6 the pixel counts of the four discrete CSR categories are for the first time aggregated to Level 3 and reported in the COP_Phase_*_Histogram_Counts SDSs (see Section 7.1.2 of the MOD08 Level 3 ATBD), though for file size reasons are only available in the MOD08_D3 daily files. Thus a cloud fraction that excludes pixels determined to be “not clear” for reasons other than cloudiness can be calculated from these histograms. For example, the cloud fraction of grid box (i,j) excluding “restored to clear” pixels from the cloudy population can be calculated as, where Cloudy, PCL, and RestoredToClear refer to the histogram counts of the cloudy, partly cloudy, and “restored to clear” CSR designations, respectively, and CloudMaskClear refers to the histogram count of the remaining MOD35 clear pixels after CSR filtering; the subscript p refers to the three individual phase bins (i.e., liquid, ice, undetermined) in the Cloudy and PCL histograms. Note this fraction represents the “cloudy” pixel population for which MOD06 attempts cloud optical property retrievals. A final caveat regarding the importance of instrument limitations should be addressed here. At 1km spatial resolution, MODIS is able to detect most cloud types, optically thin cirrus clouds notwithstanding. Nevertheless, it has been shown that MOD35 performs inconsistently in partially cloudy scenes, such as those with trade wind cumuli that have spatial scales much smaller than the MODIS footprint, and may overestimate grid box cloud fraction [Zhao and Di Girolamo, 2006]. While MODIS has a nominal pixel size of 1km at nadir, geometry (and instrument design) dictates that this size increases towards the edge of scan, potentially exacerbating the sub-pixel cloudiness issue.

Q: What do the "undetermined" and "combined" cloud phases mean?

A: The undetermined cloud phase means the cloud optical properties retrieval algorithm could not make a determination of the cloud phase (between liquid water clouds and ice clouds). 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 (thin cirrus overlying liquid water clouds). For these undetermined phase 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 clouds, ice clouds, and undetermined phase clouds. 

Q: There are multiple cloud phase histograms. How are these different?

A: There are two primary cloud phase products included in MOD06, namely an infrared (IR) algorithm that runs in parallel with the MOD06 cloud top (CT) properties retrieval during both daytime and nighttime [Baum et al., 2012], and a daytime-only algorithm run as part of the MOD06 cloud optical properties retrieval. In L3 the aggregated results of the IR cloud phase algorithm algorithm are reported in SDSs with Cloud_Phase_Infrared in the SDS name. The daytime-only algorithm, that employs a variety of shortwave-infrared (SWIR) based tests in addition to information from the CT and IR phase retrievals (see Section 2.4 of the MOD06 User Guide), provides the final phase decision for the MOD06 cloud optical properties retrievals. The aggregated results from this algorithm are reported in L3 in SDSs with Cloud_Phase_Optical_Properties, or simply Cloud_Phase, in the SDS name. In addition, the cloud optical and microphysical retrieval statistics in the L3 daily and multi-day products are phase-dependent, and are aggregated according to the results of the daytime-only phase algorithm (i.e., ice, liquid, undetermined, combined). Finally, users should note the results of the IR and daytime-only phase algorithms are not expected to agree in all cases. 

Q. Why are there fewer Joint Histograms in the multiday Level-3 products (08_E3 and 08_M3) than in the daily Level-3 product (08_D3)? 

A. In the latest Collection 6 PGE version (delivered in October 2014), there were 88 Joint Histograms in the D3 file.  A number of these were not propagated to the E3/M3 files due to a 2.0 GB file size limitation in HDF4. The primary reason why the Joint Histograms take up more room in the multiday files is due to the larger counts involved, the multiday Histograms and Joint Histograms had to be stored as Long (4 byte) integers to ensure there would be no integer overflow (and value wrapping) while the daily Histograms and Joint Histograms could be safely stored as Short (2 byte) integers. This doubling of the Histogram integer sizes (from 2 bytes to 4 bytes) pushed the total file size upwards to where a number of Joint Histograms had to be deleted when going from daily (D3) to eight day / monthly (E3 / M3).  

So the upshot is, a total of 27 Joint Histograms that are in the Daily L3 (08_D3) were not passed to the Multiday L3 (08_E3 and 08_M3) due to 2 GB (uncompressed) HDF file size limit in HDF4.  There are also 14 scaler SDS’s related to Cloud Optical Property (COP) Fractions and 4 marginal Histograms related to COP Phase Counts (Cloudy, Partly Cloudy, and Clear pixel counts) that are only in the D3 and not propagated to E3/M3 due to it not being vital to have those statistics in the multiday files.

Q. Why do the Cloud Top Property Daytime parameters extend slightly further poleward than the Cloud Optical Property Daytime parameters?

A. The difference in the poleward extent of  these two groups of parameters can be tracked to their differing definition of “Daytime” (where COP retrieves and where CTP define “_Day”parameters).  For Cloud Optical Properties, COP “Daytime”, where retrievals for clouds are made, is arccos (.15) = 81.3731° .  So Cloud Optical Properties retrieves when Solar Zenith Angle ≤ 81.3731°. (Sometimes this is simplified in documentation as SZA < 81.4°).  For Cloud Top Properties,  CTP “Daytime”, where the CTP group retrieves and they append "_Day" to their parameters (SDS's) in L2, is SZA ≤ 85.0°. So Cloud Top Properties calls things "_Day" in L2 when Solar Zenith Angle ≤ 85.0°.  (Note: If you dump out the Solar_Zenith_Day SDS in L2, which is using the CTP definition of "daytime",  you will see packed short integer values of 8500, but never 8501). The upshot is, COP is 3.6269° more restrictive in the Solar Zenith Angle for retrievals than the "_Day" CTP retrievals. In other words, CTP extends a bit further into the low sun angle (twilight) regions than COP: 81.3731° vs. 85.0°.

Q. Can you explain the new “PCL” Cloud Optical Property parameters for Collection 6? 

A. There are a number of new PCL (Partly Cloudy) Cloud Optical Property parameters in C6, both in the 06_L2 and L3 files.  They always have the string  “_PCL” in the SDS name.  These are slightly less reliable than the regular cloudy retrievals, therefore they were separated into a stand-alone SDS’s so that users could decide either to mix them in with the regular retrievals or leave them out.

Q. How many Histograms and Joint Histograms are defined for Cloud Optical Properties in Level-3? 

A. Listed below are the SDS counts for Cloud Optical Property Marginal (1D) and Joint (2D) Histograms: 

1. COP Joint (2D) Histogram Count       =  44 Joint Histograms

2. COP Marginal (1D) Histogram Count =  44 Marginal Histograms

Q. How do the Cloud Phase Infrared statistics differ from the Cloud Fraction (from Cloud Mask) statistics?   Can they be compared directly?

A. The Level 2 Cloud_Fraction SDS will have values of 0%, 4%, 8%, 12%, and 16% stored (as well as all increments of 4% from 16% to 100%).  Howevever the L2 Cloud_Phase_Infrared SDS will have a value of "Clear" (0) stored if the Fraction is less than 16%  So this should make the Fractions from Cloud_Phase_Infrared (which can be post-processed from the L3 Histograms) slightly SMALLER than the fractions from Cloud_Fraction (stored in L3 as a Fraction SDS). 

What follows is a bit of additional background information which highlights additional differences between these two Level-2 (and downstream Level-3 “derived from” parameters). The  06_L2 SDS   is called "Cloud_Phase_Infrared"  and  is stored at a 5km resolution  It is calculated in the same main program as the Cloud Top Property SDS’s but is a separate process and is in a separate set of subroutines.  That means the input radiances (brightness temperatures) are mean values over a 5x5 just as in the CTP process. The phase is determined from 8.5 - 11 um (band 29 - band 31) differences via a threshold table (in other words, a somewhat simple algorithm). Since that algorithm uses 5 x 5 km mean values of BTs for the algorithm, only a single result per 5x5 km grid cell is computed.

It should be noted that the 1-km phase algorithm is very different and is more complicated.  So the 1-km Cloud Fraction results will not necessarily "look right" when compared to the 5-km Cloud Phase Infared values. For Cloud Phase Infrared, the three phase designations (liquid water, ice, and undetermined) are computed for an entire 5x5, so "undetermined phase" is determined from a particular range of 8.5-11 um BTDs found in the threshold table. 

Users should note that in Collection 5 there was a “mixed” phase as well as an “undetermined” phase (along with the standard “liquid water” and “ice” phases  for the Cloud Phase Infrared results. In Collection 6 the "mixed" designation has been eliminated and now there are only 3 phase results for Cloud Phase Infrared:  liquid water, ice, and undetermined phase. This change was implemented because there was too much uncertainty and that it was too difficult to  distinguish mixed phase from ice or water. 

So in the L2 Cloud_Phase_Infrared SDS, the only valid phase values are 0 (clear), 1 (liquid water), 2 (ice), and 6 (undetermined phase).  There will not be any stored values of 3, 4, 5 in the L2 Cloud_Phase_Infrared SDS. (In C5 the value of 3 represented “mixed” phase). 

The IR phase algorithm uses the same criterion for clear vs. cloud as does the Cloud Top Properties (CTP); the 5x5 km grid cell is considered cloudy if 4 out of 25 (16%) are cloudy (confident cloudy and probably cloudy) according to the cloud mask.  Also the Cloud Phase Infrared does start with the same assumption that to be cloudy, the Cloud Mask must say confident cloudy or probably cloudy. Both CTP and IR phase require 16% cloudy to report a valid (cloudy) result.   In the case of the IR phase, the value reported for "clear" is 0.

Q. Can you explain the new "Minimum Number of Days" screen implemented in the Collection 6.1 (C061) Monthly (M3) product for all Aerosol related SDS's?

A. In Collection 6 (C006) and previous collections, it only took a single valid (non-fill) Daily (D3) grid cell within the monthly period for that same Monthly (M3) grid cell to populate.  Starting in Collection 6.1 (C061), for all Aerosol-related products in the Monthly (M3) product, it is now required that there are 3 valid (non-fill) days in order to populate that same M3 grid cell.  This logic change in the C061 Monthy (M3) product was implemented in order to reduce cloud, snow, and ice contamination in Aerosol SDS's in the Monthly product.  It should be noted that no change was made to the Eight Day (E3) product, which still uses the old heritage logic of 1 valid daily (D3) grid cell necessary to populate the eight-day (E3) grid cell.  The time-averaged coverage is now much closer between the E3 and M3 Products for Aerosol.  The E3 Product requires D3 grid cells for just 1 of 8 days (12.5%) to be valid to populate.  While the new C061 M3 logic, for Aerosol related SDS's, requires D3 grid cells for at least 3 of 30 days (10.0%) to be valid to populate.  For the aerosol science and research community, they should be aware that this '3 day min' change is now consistent between Deep Blue, Dark Target, and the Combined Aerosol SDS's in the new C061 monthly (M3) product.  This logic change in the M3 product could potentially have a large effect in poorly-sampled regions, e.g. high latitudes in local winter and monsoon systems in the tropics. Therefore, it could affect people doing trend studies. So this major logic change effort was made at the start of Collection 6.1 (C061) in order have the entire data record for Terra and Aqua redone with this change.  The new Collection number (C061) should provide more of a heads-up to Aerosol users about this logic change -- important to note because this could cause discontinuties for those comparing an older collection (C005, C051, or C006) records with the C061 record, especially since the monthly data are among the most popular products for Aerosol research.