MODIS C6 Reprocessing Proposed Changes to the Science Algorithms

**1. Introduction**

The proposed C6 changes to the science algorithm are organized as
answers from the individual teams to the following four questions.

> 1\. What changes (if any) do you feel are important to make to your
> algorithm?
>
> 2\. What upstream algorithm changes would your algorithm benefit from?
> Also, what upstream changes would necessitate a reprocessing for your
> algorithm?
>
> 3\. Based on 1 and 2, what are the significant scientific benefits
> from a C6 reprocessing for your algorithm?
>
> 4\. Are there any other changes, such as product format changes, that
> are also needed? Why?

At the end is a discussion of a set of generic changes that should be
considered for all Land algorithms, the L1B and geolocation changes, and
other upstream atmosphere algorithm changes.

**2. Surface Reflectance (MOD09/MYD09)**

*Source: Eric Vermote, UMD*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. We need to make some changes to the QA flags:
>
> a\) Introducing a more continuous index of performance for aerosol
> loading (instead of the discrete clear, average and high aerosol)
>
> b\) The QA in the CMG products needs to be updated to report
> percentage for the cloud, shadow and snow contamination.
>
> ii\. Improvement to the cloud, cloud shadow.
>
> In collaboration with LDOPE
>
> iii\. Improvement to the aerosol retrieval

a)  Based on the AERONET match-up analysis. Fine tuning of the empirical
    relationship used for aerosol retrieval and correction. Introduction
    of the BRDF coupling in the aerosol inversion.

> iv\. Improvement to the atmospheric correction

a)  Introduce correction for BRDF coupling term based on BRDF database.

> v\. Correction for BRDF effect in 8 days composite surface reflectance
> product.\
> Also gapped filled this product.

2\. What upstream algorithm changes would your algorithm benefit from?
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> Level 1B changes: Improved calibration. Characterization of the
> polarization effect in band8.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> Consolidate and refine the accuracy and precision of the product. Make
> the 8days product more useful to the overall community.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> The format will change slightly (but we can make backward compatible)
> as a result of the QA changes.

**3. Vegetation Indices (MOD13/MYD13)**

*Source: Alfredo Huete, Arizona University*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. improve temporal frequency (in response to user community
> requests).
>
> ii\. implement a temporal gap filling routine
>
> iii\. snow/ice remain problematic and a solution has been outlined
>
> iv\. resolve the inland water bodies issue (false green signals)
>
> v\. strengthen and formalize the EVI2 backup algorithm
>
> vi\. adjust VI dynamic range to better handle negative values.

2\. What upstream algorithm changes would your algorithm benefit from?
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> i\. An upstream benefit for the VI product would be to provide a
> "non-aerosol correction" option over problematic seasonal/ephemeral
> water areas.
>
> ii\. The VI product is very sensitive to upstream surface reflectance
> changes, both individual blue, red, and NIR reflectances, as well as
> their coherencies. The VI product will need to carefully evaluate
> impacts caused by improvements/ changes to the surface reflectance
> product.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> i\. Provide a higher frequency VI product of particular use to the
> emerging phenology community.
>
> ii\. Provide gap filled data to the biogeochemical and climate
> modeling communities.
>
> iii\. Provide a more accurate VI product to meet the needs of
> scientists working in wetlands and northern (snow-covered) latitudes.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> None at the moment.

**4. BRDF/Albedo (MCD43A, MCD43B, MCD43C)**

*Source: Crystal Schaaf, Boston University*

C6 Efforts

> i\. Fine tune our quality assessments and improve our quality fields.
>
> ii\. Improve the backup algorithm (make it more dynamic and more
> representative of the finer resolution).
>
> iii\. Move to L2GLite (once it is fixed).

Useful efforts (even if not archived):

> i\. Generate a 250m gridded product for just the first two bands
>
> ii\. Multiday retrievals more frequently (4 days instead of 8?)

Reasons

> Improve usability of the quality flags and improve the quality of the
> backup algorithm, thus improving the overall global quality for gap
> filling, for data assimilation and for climate modeling. L2Glite
> allows the users access to the same inputs.

**5. LAI/Fpar (MOD15/MYD15)**

*\[list of changes needed\]*

**6. Net Photosynthesis (MOD17/MYD17)**

*Source: Maosheng Zhao, NTSG*

Before I answer the four questions, let me first clarify some awkward
situations of MODIS GPP/NPP products. From our experience, two major
inputs have large impacts on MODIS GPP/NPP. One is MODIS 8-day FPAR/LAI,
and the other is daily GMAO/NASA meteorological reanalysis data. Due to
the Simultaneity requirement for the C5 reprocessing, the
Biome-Look-UP-Table (BPLUT) for the official C5 MODIS GPP/NPP was tuned
based on the C4 FPAR/LAI and an old version of GMAO/NASA data, because
there is no available C5 FPAR/LAI data for at least one entire year.
That\'s why a user has found that our C4.8 improved GPP is even better
than C5 GPP when compared them with GPP at an eddy flux tower in
Australia. For the C6, the similar problem may happen again because we
will have to tune BPLUT based on C5 MODIS FPAR/LAI. Or we may have to
postpone the delivery of C6 PGE36/37 to MODAPS if the new version of
GMAO/NASA for 2000 to 2007 is released later.

Anyway, as previous, our NTSG will regenerate the improved, consistent,
high quality MODIS GPP/NPP, and these data from MODAPS will serve as
near realt-time GPP though less reliable than the improved one. Below is
the answer to your questions.

1\. What changes (if any) do you feel are important to make to your
algorithm?

> For C6 MODIS GPP/NPP algorithm, we will only change BPLUT. Though new
> version GMAO data will have a different spatial resolution (about half
> of the old version), PGE36/37 code automatically handles that.

2\. What upstream algorithm changes would your algorithm benefit from?
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> MODIS GPP/NPP are influenced by MODIS FPAR/LAI, and a non-MODIS data
> set, GMAO/NASA meteorological data set. MODIS FPAR/LAI is required to
> reprocessing for the input of MODIS GPP/NPP.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> With improvements in C6 MODIS land cover and FPAR/LAI quality, and new
> version GMAO/NASA data set, MODIS GPP/NPP will be more reliable.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> No other changes.

**7. Vegetation Continuous Fields (MCD44)**

*Source: Mark Carroll, UMD*

It is difficult to answer these questions point by point since we have
not yet completed our C5 product, but essentially my response would be
that if there are significant positive changes to the surface
reflectance product, it could make a significant positive change in our
output product. To this end it would be demonstrative to see a report on
the stability of the surface reflectance product through the lifetime of
the MODIS instrument. Perhaps the LDOPE can do a summary report of the
time series plots for the Golden Tiles. Bottom line for us is that if
there is a collection 6, I would like to have our data collector (aka
PGE72 which produces MOD44C) running so that we could conceivably make a
C6 VCF, but I wouldn\'t know for sure that it would happen until we saw
the differences between C5 and C6.

**8. Burned Area (MCD45A)**

*Source: David Roy, South Dakota State University*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. Fix a bug handling Aqua data in concert with Terra in the
> intermediate product (MCD45A2).
>
> ii\. Potential improvement to MOD/MYDHDFSR handling of MOD09 cloud and
> aerosol bits & masking. (Note we are responsible for MOD/MYDHDFSR).
>
> iii\. Introduce Active Fire (MOD14A1) data to refine the output of the
> intermediate product (MCD45A2) to give a more robust final product
> (MCD45A1).

2\. What upstream algorithm changes would your algorithm benefit from?

> Also, what upstream changes would necessitate a reprocessing for your
> algorithm?
>
> i\. Any upstream changes to the content of MOD09 L2G (full) including
> reflectance, aersols, and clouds will necessitate a reprocessing for
> the burned area algorithm.
>
> ii\. Any changes to MOD09 L2G (full) structure, this is used to
> generate MOD/MYDHDFSR, will certainly need through testing.
>
> iii\. Potential improvement to MOD/MYDHDFSR handling of MOD09 cloud
> and aerosol bits & masking. (Note, we are responsible for
> MOD/MYDHDFSR)

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> An improved product. Note, Collection 5 is the first time we have run
> the burned area algorithm globally. We know from SCF testing that we
> can make a better Collection 6 product.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> For Collection 6 we plan to introduce an annual 500m summary product.

**9. Land Cover/Dynamics (MCD44)**

*Source: Mark Friedl, Boston University*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. For MOD12Q1:
>
> a\. Migrate to a LCCS compliant classification scheme. This would
> effectively remove the need for additional SDS\'s beyond primary
> classification.
>
> b\. Develop solution to stabilize classification results across years,
> perhaps via hybrid change-classification algorithm.
>
> c\. Improved treatment for difficult classes (urban, wetlands, ag)
>
> ii\. For MOD12Q2:
>
> This algorithm is still in relatively early stages of development; C4
> was first implementation. Hence, a number of refinements will likely
> emerge based on C5 results. Immediately obvious options include:
>
> a\. Moving to a 250-m product
>
> b\. Use of higher frequency inputs (currently using rolling 16-day
> data at 8-day intervals).
>
> c\. Improved detection and screening of snow
>
> d\. Gap filling to reduce missing values
>
> e\. Use of asymmetric sigmoid for OLS fitting

2\. What upstream algorithm changes would your algorithm benefit from?\
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> i\. We would benefit the most from:
>
> a\. Improved land/water mask
>
> b\. Improved cloud mask (currently missing a lot of data over some
> glaciers and urban areas)
>
> c\. 250-m NBAR data at higher temporal frequency
>
> ii\. Any upstream changes, assuming they improve data quality, would
> suggest that reprocessing for our algorithm would be beneficial.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> i\. Better representation/characterization, higher accuracy of land
> cover
>
> ii\. More robust, precise and accurate estimates of phenology.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> Nothing beyond what I\'ve already indicated.

**10. Thermal Anomalies/Fire (MOD14/MYD14)**

*Source: Louis Giglio, UMD*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. Refine internal cloud mask, which sometimes flags heavy smoke as
> cloud. This can cause the algorithm to miss portions of large, very
> obvious fire fronts. The internal cloud mask also sometimes flags
> bright desert and snow as cloud. Although in these cases no fires are
> missed, the masking should be corrected since some use the mask for
> rudimentary general-purpose cloud masking.
>
> ii\. Fix for frequent false alarms in the Amazon which are caused by
> small (\~1 km) clearings within forest.
>
> iii\. Fix (i) for very obscure bug which causes cloud and water pixels
> adjacent to fire pixels to be incorrectly counted when they are near
> the scan edge.

2\. What upstream algorithm changes would your algorithm benefit from?\
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> i\. Improved calibration in any of the primary fire bands (21, 22, and
> 31).
>
> ii\. Improved land/sea mask.
>
> Note that neither (i) nor (ii) necessitate reprocessing but will
> improve the product.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> Improved product greatly so in the case of the Amazon (false alarms
> are currently high here).

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> None.

**11. Snow Cover/Sea Ice (MOD10/MYD10, MOD29/MYD29)**

*Source: Dorothy Hall, GSFC NASA*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. Collaborate with BU to provide an improved daily snow albedo
> algorithm;
>
> ii\. Produce a new product that is an experimental/beta \"cloud-free\"
> product; in other words, we would make assumptions about snow cover
> under clouds so that modelers who need snow cover daily everywhere
> could use the product without clouds;
>
> iii\. Refine the way we are using the cloud mask to improve snow/cloud
> discrimination for purpose of snow mapping

2\. What upstream algorithm changes would your algorithm benefit from?
Also, what upstream changes would necessitate a reprocessing for your

algorithm?

> i\. A less-conservative cloud mask that does a better job of
> distinguishing snow/ice from cloud would dramatically improve our
> algorithm.
>
> ii\. Changes in L1B products could affect the snow and sea ice
> algorithms. Major improvements in L1B would necessitate a
> reprocessing, especially for fractional snow part of algorithm.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> Our largest source of error in snow mapping is, by far, the
> conservative nature of the cloud mask over snow (e.g., much more cloud
> is masked than is really present). Significant scientific benefit from
> improved snow/cloud discrimination would be increased accuracy in
> mapping snow cover area.
>
> A "cloud-free" product should provide improved representation of snow
> covered area changes over short and long time periods.

4\. Are there any other changes, such as product format changes, that
are

also needed? Why?

> i\. Correct a metadata error in MOD29E1 because grid dimensions are
> reversed and may result in flipped maps when the projection or data
> product format is changed.
>
> ii\. Some minor corrections in local attributes to improve consistency
> of data documentation in products are also needed.

**12. Land Surface Temperature (MOD11/MYD11)**

*Source: Zhengming Wan, UCSB*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. remove cloud-contaminated LSTs not only from level-3 LST products
> but also from level-2 LST products (MOD11_L2 and MYD11_L2).
>
> ii\. update the coefficient LUT (lst_coef.h) for the split-window
> algorithm with comprehensive regression analysis of MODIS simulation
> data in bands 31 and 32 over wide ranges of surface and atmospheric
> conditions, especially extending the upper boundary for (LST --
> Ts-air) in arid and semi-arid regions and increasing the overlapping
> between various sub-ranges in order to reduce the sensitivity of the
> algorithm to the uncertainties in the input data (i.e., column water
> vapor and air surface temperature from MOD07 and MYD07).
>
> iii\. make minor adjustments in the classification-based surface
> emissivity values (band_emis.h), especially for land-cover type of
> bare soil and rocks.
>
> iv\. tune the day/night algorithm by adjusting weights to improve its
> performance in desert regions where the incorporated split-window
> algorithm may not work well.
>
> v\. generate new LST products for 8-day and monthly at 6km grids (in
> response to user community requests).

2\. What upstream algorithm changes would your algorithm benefit from?\
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> i\. benefit from improvements in upstream products MOD02, MOD03,
> MOD07, MOD35, MOD10, MOD12 and MOD43 (with impacts roughly in the
> reducing order).
>
> ii\. any significant changes in the above upstream products would
> necessitate a reprocessing for the LST products.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> i\. improve the accuracies of LSTs and emissivities in the LST
> products.
>
> ii\. improve the stability of the retrieved surface emissivities in
> the LST products, especially in the desert regions.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> i\. add flexibility to input options in the daily PGE16 if the need
> for near real-time processing capability can be better met without
> scarifying the LST quality, TBD.
>
> ii\. correct effects of thin cirrus clouds and aerosols on the C6 LST
> products, TBD.

**13. Generic Changes**

*Source: Sadashiva Devadiga, LDOPE NASA*

Some generic issues to be addressed in the C6

i\. Using one Cloud Mask (MOD09 internal or MOD35 cloud mask, not both)

> MOD09 uses only internal cloud mask. Downstream PGEs have been using
> some combination of MOD35 cloud mask and MOD09 internal cloud mask.
> This is very confusing and is also not quite correct - cloud shadow,
> aerosol flag, snow are not going to be consistent with this combined
> cloud flag.
>
> LDOPE is willing to do a thorough evaluation of MOD09 internal cloud
> mask and at the same time I would expect Eric to fix any outstanding
> issue so that we can use just the MOD09 internal cloud mask.

ii\. Fixing L2G lite and using L2G lite in all of the downstream

> L2G lite is currently being distributed while we still have products
> that use regular L2G (VI, Lai/Fpar, Fire, BA, LCC). BRDF/Albedo has a
> working code, however the SCF have some issue with the L2G lite. I am
> assuming that Robert Wolfe is going to address this issue.
>
> We should ask the teams to update the downstream PGEs to use L2G lite.
> We should compare and evaluate products generated from L2G lite and
> L2G regular and then fix any L2G-lite issues that may be affecting the
> downstream product quality.

iii\. Stop supporting MODAGAGG

> This is an input to 1km VI and 1km Lai/Fpar. I really don\'t think it
> is worth maintaining this software anymore. This is an intermediate
> product and is not distributed.

iv\. Do we need 1km product when we have the same product at 500m
resolution?

> May be not.

**14. L1B and Geolocation**

*L1B Source: Brian Wenny, MCST NASA*

  ---- --------------- ----------- -------- -------------- ---------- ----------------
  \#   Issue           Personnel   Change   Change Status  Test Data  
                                   Type                    Produced   

  1    Fill vs         JK, XG, BW  Code     **Complete**   Yes        L1B code changes
       Interpolation                                                  complete. 1-day
       for dead                                                       'golden tile'
       detectors                                                      data produced.
                                                                      Awaiting
                                                                      approval from
                                                                      Science Teams

  2    Noisy/Dead      JK, XG, JS, Code,    **Complete**   In process L1B code changes
       Subframe        BW          LUT                                and new QA LUT
                                                                      complete. Test
                                                                      data produced,
                                                                      undergoing
                                                                      internal review

  3    A0/A2 update    AW, BW, CM  LUT      Initial table  No         Initial V6 LUT
                                            derived                   derived.
                                                                      Selected
                                                                      granules
                                                                      produced and
                                                                      undergoing
                                                                      internal review.

  4    Reprocess m1    JS, HC, AA, LUT      **Complete**   No         
       (Current        JC                                             
       algorithm)                                                     

  5    m1 Correction   JS, HC, AA, LUT      In process     No         Analysis pending
                       JC                                             

  6    Detector        JS, AW, HC, LUT      In process     No         Initial Terra
       Dependent RVS   AA, JC                                         LUT derived,
                                                                      under review.
                                                                      Aqua analysis
                                                                      underway

  7    SV DN=0         JK, XG, SM, Code     In process     No         Compiling
                       BW                                             statistical
                                                                      information

  8    QA LUT ASCII    BW          LUT      **Complete**   No         Error corrected
       Format Error                                                   in V5 QA update.
                                                                      QA flag (bit 3)
                                                                      for B21 D10
                                                                      (Aqua) will be
                                                                      reinserted in
                                                                      V6.

  9    Metadata --     JK, JS, XX,          TBD            No         Input required
       Polarization    RW                                             as to what
       info                                                           info/format is
                                                                      to be included
                                                                      and how it will
                                                                      be inserted into
                                                                      the metadata
  ---- --------------- ----------- -------- -------------- ---------- ----------------

4/11/08 Update

*RSB: [Preliminary]{.underline}* Estimate of Impact of Proposed
Collection 6 Changes (Analysis still ongoing for several issues)

+-----+---------+---------+----------+---------+--------------------+
|     | **Col   |         |          |         |                    |
|     | lection |         |          |         |                    |
|     | 6       |         |          |         |                    |
|     | Issue** |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| B   | **1**   | **2**   | **4**    | **5**   | **6**              |
| and |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 1   |         |         |          | Terra:  |                    |
|     |         |         |          |         |                    |
|     |         |         |          | All     |                    |
|     |         |         |          | bands:  |                    |
|     |         |         |          | can be  |                    |
|     |         |         |          | up to   |                    |
|     |         |         |          |         |                    |
|     |         |         |          | +/-     |                    |
|     |         |         |          | 0.5%,   |                    |
|     |         |         |          | mainly  |                    |
|     |         |         |          | for     |                    |
|     |         |         |          | recent  |                    |
|     |         |         |          | data    |                    |
+-----+---------+---------+----------+---------+--------------------+
| 2   |         | Terra:  |          |         |                    |
|     |         |         |          |         |                    |
|     |         | D29 &   |          |         |                    |
|     |         | 30      |          |         |                    |
|     |         | s       |          |         |                    |
|     |         | ubframe |          |         |                    |
|     |         | 1       |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 3   |         |         |          |         | Terra: Time        |
|     |         |         |          |         | dependent,         |
|     |         |         |          |         |                    |
|     |         |         |          |         | 0 to +/- 1.5%      |
+-----+---------+---------+----------+---------+--------------------+
| 4   |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 5   | Aqua:   |         |          |         |                    |
|     | D20     |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 6   | Aqua:   |         |          |         |                    |
|     | D       |         |          |         |                    |
|     | 10,12-1 |         |          |         |                    |
|     | 6,18-20 |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 7   |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 8   |         |         | Terra:   |         | Terra: Time        |
|     |         |         | Up to 1% |         | dependent,         |
|     |         |         | due to   |         |                    |
|     |         |         | deg      |         | 0 to +/- 2.5%      |
|     |         |         | radation |         |                    |
|     |         |         | r        |         |                    |
|     |         |         | efitting |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 9   |         |         |          |         | Terra: Time        |
|     |         |         |          |         | dependent,         |
|     |         |         |          |         |                    |
|     |         |         |          |         | 0 to +/- 2%        |
+-----+---------+---------+----------+---------+--------------------+
| 10  |         |         |          |         | Terra: Time        |
|     |         |         |          |         | dependent,         |
|     |         |         |          |         |                    |
|     |         |         |          |         | 0 to +/- 1%        |
+-----+---------+---------+----------+---------+--------------------+
| 11  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 12  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 13  |         |         |          |         |                    |
| H/L |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 14  |         |         |          |         |                    |
| H/L |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 15  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 16  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 17  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 18  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 19  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+
| 26  |         |         |          |         |                    |
+-----+---------+---------+----------+---------+--------------------+

Notes:

-   Issue 1 & 2 -- the indicated detectors (subframe) will be fill
    values in L1B (not interpolated values as in the current V5 data).

-   Issue 4 -- Terra: all other bands impact estimated to be very small

*TEB: [Preliminary]{.underline} Estimate of Impact of Proposed
Collection 6 Changes*

+------+---------+-----------------------------------------------------+
|      | Col     |                                                     |
|      | lection |                                                     |
|      | 6 Issue |                                                     |
+------+---------+-----------------------------------------------------+
| Band | **1**   | **3**                                               |
+------+---------+-----------------------------------------------------+
| 20   |         | Terra: Radiance Difference up to +/- 0.2% at L~typ~ |
|      |         | (+/- 0.05 K)                                        |
+------+---------+-----------------------------------------------------+
| 21   |         |                                                     |
+------+---------+-----------------------------------------------------+
| 22   |         | Terra: +/- 0.05% at L~typ~ (+/- 0.05 K)             |
+------+---------+-----------------------------------------------------+
| 23   |         | Terra: +/- 0.2% at L~typ~ (+/- 0.05 K)              |
+------+---------+-----------------------------------------------------+
| 24   |         | Terra: +/- 2.5% at L~typ~ (+/- 0.5 K)               |
+------+---------+-----------------------------------------------------+
| 25   |         | Terra: +/- 0.4% at L~typ~ (+/- 0.1 K)               |
+------+---------+-----------------------------------------------------+
| 27   |         | Terra: +/- 1.5% at L~typ~ (+/- 0.3 K)               |
+------+---------+-----------------------------------------------------+
| 28   |         | Terra: +/- 2.0% at L~typ~ (+/- 0.5 K)               |
+------+---------+-----------------------------------------------------+
| 29   | Terra   | Terra: +/- 0.1% at L~typ~ (+/- 0.05 K)              |
|      | D6      |                                                     |
+------+---------+-----------------------------------------------------+
| 30   |         | Terra: +/- 1.0% at L~typ~ (+/- 0.3 K)               |
+------+---------+-----------------------------------------------------+
| 31   |         | Terra: +/- 0.07% at L~typ~ (+/- 0.05 K)             |
|      |         |                                                     |
|      |         | Aqua: +/- 0.07% at L~typ~ (+/- 0.05 K)              |
+------+---------+-----------------------------------------------------+
| 32   |         | Terra: +/- 0.07% at L~typ~ (+/- 0.05 K)             |
|      |         |                                                     |
|      |         | Aqua: +/- 0.07% at L~typ~ (+/- 0.05 K)              |
+------+---------+-----------------------------------------------------+
| 33   |         | Terra: +/- 0.15% at L~typ~ (+/- 0.1 K)              |
+------+---------+-----------------------------------------------------+
| 34   |         | Terra: +/- 0.17% at L~typ~ (+/- 0.1 K)              |
+------+---------+-----------------------------------------------------+
| 35   |         | Terra: +/- 0.2% at L~typ~ (+/- 0.1 K)               |
+------+---------+-----------------------------------------------------+
| 36   | Aqua D5 | Terra: +/- 0.22% at L~typ~ (+/- 0.1 K)              |
+------+---------+-----------------------------------------------------+

Notes:

-   Issue 1 -- the indicated detectors will be fill values in L1B (not
    interpolated values as in the current V5 data).

-   Issue 3 -- Noisy detectors are excluded in the estimates.
    Differences are scene temperature dependent, typically with larger
    differences at the low temperature extremes

*Geo Source: R. Wolfe, GSFC NASA*

1\. What changes (if any) do you feel are important to make to your
algorithm?

> i\. Update error analysis based on C5 residuals, update long-term
> trend, biases and sun-angle corrections
>
> ii\. Incorporate new ancillary data
>
> a\. Shuttle Radar Terrain Mission (SRTM) Digital Elevation Model data
> (500m below 60 latitude?)
>
> b\. Land/water mask based on SRTM (or other) data (500m?)
>
> iii\. Updated ground control points based on improved GeoCover Landsat
> 7 products
>
> iv\. Further improve maneuver handling
>
> v\. Compute 500 m geolocation (using 500m DEM) and provide in the form
> of 8-bit offsets from a bilinear-interpolation of the 1 km data
>
> vi\. Enhanced 1 km terrain correction (area based) -- less additional
> computation is needed if combined with (v)
>
> vii\. Develop and implement an algorithm to remove the AMSR-E jitter
> from the long-scan mirror motion for MODIS/Aqua

2\. What upstream algorithm changes would your algorithm benefit from?
Also, what upstream changes would necessitate a reprocessing for your
algorithm?

> None.

3\. Based on 1 and 2, what are the significant scientific benefits from
a C6 reprocessing for your algorithm?

> i\. Retroactively applying the long-term trend will reduce the
> geolocation error over certain time periods. For Aqua, this would be
> the first time that a sun-angle correction is performed. Only a small
> change is expected in the overall Root Mean Square (RMS) error. But,
> there will be larger improvements in some regions (e.g. polar regions
> for an Aqua Sun angle adjustment).
>
> ii\. Improvements in the DEM, Land/water mask will improve the overall
> scientific quality of the geolocation and downstream products.
>
> iii\. Improved maneuver handling, 500m geolocation and area based
> terrain correction has the potential to improve the overall quality of
> downstream land products under certain conditions (near maneuvers and
> over rugged terrain).
>
> iv\. Removing the AMSR-E jitter could improve MODIS/Aqua scan
> direction geolocation accuracy.

4\. Are there any other changes, such as product format changes, that
are also needed? Why?

> i\. Write spacecraft temperature to geolocation product, for transfer
> to the Control Point Residuals file, to better characterize thermal
> effects on geolocation accuracy
>
> ii\. Write the long term trend and solar elevation correction (roll,
> pitch and yaw) to geolocation product, for transfer to the Control
> Point Residuals files
>
> iii\. Add a scan SDS reporting the quality and type of the
> ephemeris/attitude data used in our calculations
>
> iv\. Correct the setting of attitQuat when EA Source is \"MODIS
> Packet\" (of interest only for Direct Broadcast users). When that
> source is used, the attitQuat is currently set to a constant value
> indicating nominal orientation (roll, pitch, and yaw are all zero).
> attitQuat is used only in the calculation of the solar \"elevation\"
> angle correction.

**15. L2G, L2G-lite Changes**

*Source: R. Wolfe, GSFC NASA*

i\. L2G-lite: make any changes needed so that it will work with
remaining downstream algorithms (i.e. BRDF/Albedo).

ii\. Add additional 1km information useful for burned area and other
downstream algorithms (i.e. aerosols, other bands?)

iii\. In L2G-lite, store the extra layers in the "full", not "compact"
format. Since internal HDF compression is being used, this will not
cause a significant increase in product size.

iv\. If a 500m geolocation is produce, use it in the 500m and 250m
pointer calculations.

**16. MAIAC Atmospheric Correction**

*Source: A. Lyapustin, UMBC*

The new atmospheric correction algorithm MAIAC will be ready by
September 2008, for initial testing as an alternative algorithm.

MAIAC uses a time series and an image based rather than pixel-based
processing. It is a generic algorithm which works over all land surface
types. It has an internal Cloud Mask with shadow detection, generic
aerosol-surface algorithm to derive spectral regression coefficients,
aerosol retrieval algorithm, and an atmospheric correction part. MAIAC
has an internal dynamic land-water-snow classification and a surface
change mask which allows it to flexibly choose processing path over
different surfaces.

MAIAC products (in gridded format at 1 km resolution):

> i\. Cloud Mask
>
> ii\. Land-Water-Snow Mask
>
> iii\. Aerosol Optical Thickness and Angstrom parameter (or aerosol
> model)
>
> iv\. Land surface parameters (spectral):
>
> a\. coefficients of Li-Sparse Ross Thick (LSRT) BRF model;
>
> b\. NBRF: BRF normalized to a common view geometry (VZA=0; SZA=45).
> NBRF is analogous to MOD43 NBAR;
>
> c\. IBRF -- instantaneous BRF (BRF retrieved from the last day of
> measurements using known spectral shape of BRF for a given pixel from
> previous retrievals). Analogous to MOD09 product;
>
> d\. Albedo (a ratio of reflected to incident radiative fluxes).
>
> v\. When snow is detected on the ground, aerosol retrievals are
> currently not made. In this case, MAIAC produces sub-pixel snow grain
> size and snow fraction using spectral unmixing algorithm. These
> parameters are produced in addition to IBRF and Albedo from the last
> day of measurements.
>
> vi\. QA flag.

MAIAC produces gapless products for BRF coefficients, NBRF and albedo.
When no processing can be made because of clouds, the gaps are filled-in
with the pixel-specific values from the previous retrieval. This is the
most natural way of gap-filling for relatively short periods of time,
which only assumes that the surface has been stable.

Because this is a new algorithm which was not used in operational
processing before, the first three questions do not apply in this case.

**17. Other upstream discipline changes (cloud mask, aerosols, etc.)**

*\[list of changes needed\]*