MODIS Average quality level

[chaeck]

Hi all,

I am looking at trends of SST horizontal gradients and variability, and artefacts in yearly averages have prompted me to look at the SST quality level.

When averaging over a couple of months (I have tried years 2008 and 2020), the quality level (qual_sst4) is showing higher values in a rectangle spanning 105W-105E ; 30N-10S (see attached plot for the year 2008). This is also noticable in the SST variability, for instance the SST standard deviation in a rolling window is higher in the same rectangle.

I am using the L3 daily nighttime SST4 V2019 (https://podaac.jpl.nasa.gov/dataset/MODIS_AQUA_L3_SST_THERMAL_DAILY_4KM_DAYTIME_V2019.0), downloaded with the podaac-data-downloader. I have computed the average with xarray and nces to similar results.
This does not show in the yearly product (https://podaac.jpl.nasa.gov/dataset/MODIS_AQUA_L3_SST_MID-IR_ANNUAL_4KM_NIGHTTIME_V2019.0).

Could that be an expected consequence of the processing? I don't have any clue as to where this could come from.

Thanks,

[PODAAC - edward.m.armstrong]

Sorry I will respond below. Somehow I deleted my original comment and messed things up a bit.

[chaeck]

Thank you for your response.

What I meant is that there is a sharp increase in average quality level inside that rectangle. Maybe to make it clearer, here is a zoom on the south-east corner.

Erratum: the link in the first post is wrong, I used the Mid-IR / SST4 product. In fact, the issue is not showing on the Thermal-IR / SST product.

[PODAAC - edward.m.armstrong]

Thanks, I did see the issue in the figure in the original post, so that is noted but its clearer in the zoomed figure of your response.

I believe this is an issue with the cloud masking decision tree, but I will try to confirm with the MODIS SST algorithm developers at the Univ of Miami. Give me a few days.

[PODAAC - edward.m.armstrong]

Hi,

I did discuss this artifact with an MODIS algorithm developer and scientist. Would you have the bandwidth to take deeper dive into problem? Several things could be done over the study region that shows a boundary problem:
1. Confirm the problem does not exist in either the Daytime or Nighttime MODIS L2 Daily SST product (maybe you have already done that)
2. A plot of the QL=0 and a separate plot QL=1 per pixel count. Do the boundaries show up in plots like that?
3. Recreate your original plots but just scaled 0 to 1 on colorbar
3. How about Daily Terra SST4 ? Do the same issues appear there when looking at the QLs?
4. Do the same boundaries show up with using SST variable ?

I'll start working on this as time permits next week too.

regards,
Ed Armstrong

[OB.DAAC - SeanBailey]

This is most definitely an artifact of the cloud screening algorithm. There is an explicit test applied to the region you identified. That test sets the quality flag to a minimum of 2 (and sets the SSTREFDIFF bit in the flags_sst for that pixel) if the computed SST value is significantly less than the reference SST value.

Regards,
Sean

[PODAAC - edward.m.armstrong]

Hi Sean,

Are those cloud screening tests are latitudinally based ? That is not the case here where a clear rectangle "box" is seen.

For the SST algorithm itself there are dependencies on latitudinal based coefficients but that is not what these plots are showing.

regards,
Ed

[OB.DAAC - SeanBailey]

It has nothing to do with the "latband" coefficients.
There is an explicitly defined geographic box where that test is applied:

Code: Select all

    const float equatorialNorth = 30.0; // the ranges where SST diff tests are applied
    const float equatorialSouth = -10.0;
    const float equatorialWest = -105.0;
    const float equatorialEast = 105.0;

Sean