Atmospheric correction error with AOD < 0.0103

[lledoux]

I've been able to process indices for many other tiles and dates, but for some reason, gips doesn't like this one- /scratch/lledoux/data/landsat/tiles/188052/2014030/LC08_L1TP_188052_20140130_20170426_01_T1.tar.gz

Gips will create the cloudmask (and it's visually correct), but the error I get when attempting to process the indices is

(test-venv) lmelendy@nile:/scratch/lledoux/data/landsat/tiles/188052/2014030$ gips_process landsat -t 188052 -d 2014-027,2014-032 -p ndvi       
GIPS Data Processing (v0.9.1-dev)
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG

Fatal: 1 error(s) occurred:
Problem running 6S atmospheric model: 6S returned an error (shown above) - check for invalid parameter inputs ```

[lledoux]

and the verbose output I get is

Retrieving inventory for site tiles
fname
LC08_L1TP_188052_20140130_20170426_01_T1.tar.gz
C1 asset
Processing [ndvi] on 1 dates (1 files)
LC08_L1TP_188052_20140130_20170426_01_T1_B1: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B2: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B3: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B4: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B5: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B6: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B7: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B9: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B10: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B11: GeoResource Open (use_count = 1)
LC08_L1TP_188052_20140130_20170426_01_T1_B1: read in 0:00:13.259520
Running atmospheric model (6S)
Retrieving inventory for site tiles
MOD08_D3.A2014030.006.2015073074034: GeoResource Open (use_count = 1)
MOD08_D3.A2014030.006.2015073074034[Aerosol Optical Thickness at 0.55 microns for both Ocean (best) and Land (corrected): Mean]: read (187,77)-(189,79) in 0.00403418 seconds
MOD08_D3.A2014030.006.2015073074034: ~GeoResource (use_count = 1)
ltad030: GeoResource Open (use_count = 1)
ltad030[]: read (187,77)-(189,79) in 5.8294e-05 seconds
ltad030[]: read (187,77)-(189,79) in 2.224e-06 seconds
ltad030: ~GeoResource (use_count = 1)
AOD: LTA-Daily = -0.001, -0.001
lta: GeoResource Open (use_count = 1)
lta[]: read (187,77)-(189,79) in 5.3671e-05 seconds
lta[]: read (187,77)-(189,79) in 2.025e-06 seconds
lta: ~GeoResource (use_count = 1)
AOD: LTA = 0.22644, 0.262371
AOD: Source = Weighted estimate using MODIS LTA values Value = -0.00187018166074
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG

Fatal: 1 error(s) occurred:
Problem running 6S atmospheric model:

[ircwaves]

can you try running an ndvi-toa job

[lledoux]

It ran to completion, and the image appears visually correct

(test-venv) lmelendy@nile:/scratch/lledoux/data/landsat/tiles/188052/2014030$ gips_process landsat -t 188052 -d 2014-030 -p ndvi-toa
GIPS Data Processing (v0.9.1-dev)
 -> 188052_2014030_LC8: processed ['ndvi-toa'] in 0:00:29.181117

[lledoux]

the same exact thing is happening with /scratch/lledoux/data/landsat/tiles/191051/2016041/LC08_L1TP_191051_20160210_20170330_01_T1.tar.gz

gips will process a cloudmask and ndvi-toa, but get error when attempting to process ndvi

[lledoux]

also happening for /scratch/lledoux/data/landsat/tiles/188052/LE07_L1TP_188052_20151024_20161018_01_T1.tar.gz

and /scratch/lledoux/data/landsat/tiles/188053/2014342/LE07_L1TP_188053_20141208_20161030_01_T1.tar.gz

[lledoux]

There are five folders in /titan/data/landsat/quarantine/, "2014030", "20140358", "2014324", "2015271", "2016041" that contain files that I have been having difficulty with as far as this atmospheric correction issue is concerned.

[ircwaves]

Thanks @lledoux !

[naterubin]

So it looks like this happens when the AOD value from the composites ends up being 0 with a variance of 0. This leads to bad division, which is the underlying error. After talking with Steve, we're going to use a variance of 50% of the AOD value when the variance is zero, or .15 if the AOD value is also zero.

[naterubin]

It's also worth noting that there simply isn't an AOD value for the 2014030 tile, so that is legitimately throwing an "Unable to fetch AOD" error.

[ircwaves]

379 merged and test-driven...I think @naterubin has a PR coming with updates to the system tests, eventually, right?

[naterubin]

Yes, very soon!

[ircwaves]

So, our AOD retrieval change almost squashes this bug:

$ gips_process landsat -v5 -s /scratch/lledoux/pula/pula_export_hull.shp -d 2012-305 -p cloudmask  evi  lswi  msavi2  ndvi  satvi  vari
GIPS Data Processing (v0.9.1-dev)
    [ snippedy ]
Running atmospheric model (6S)
Retrieving inventory for site tiles
AOD: Source = MODIS (MOD08_D3) Value = -0.026
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG

It seems that negatives throw IEEE_INVALID_FLAG warnings. If the AOD value is smaller than approximately 0.0103, then sixs fires off IEEE_DENORMAL and IEEE_UNDERFLOW warnings. (0.0103 was found by manual bisection method).

@bhbraswell and/or @stephenhagen -- Seems like it might make sense to set visibility to a huge value in the case of small AOD. A comparison of the results may be in order. The code would be something like:

if self.aod[1] < 0.0103:
    s.visible = 1000
else:
    s.aot550 = self.aod[1]

[ircwaves]

:ping_pong: @bhbraswell @stephenhagen @justinfisk -- thoughts on this approach? Not optimal, but seems like sixs doesn't like low or negative AOD values.