New GOES17 solar calculation error at DWR

[gjscheer-ucd]

There is a new unresolved solar calculation error from the DWR GOES17 dev processor. For 20190421 GRASS inexplicably returns NaN values for N calculations even though B2 data is good (no zeros or NaN) for any given time. See:

cimis-goes-r.cstars.ucdavis.edu:/home/gjscheer/gdb/solar/20190421-goes17-dwr

Specifically the issue starts at 1046PST and propagates throughout the day. I've used QGIS to verify good B2 data (there is a min / max log of all bands for that day).

[qjhart]

@gjscheer-ucd, this is indeed a strange error. We can pretty easily track down the problem, but the trick will be to figure out how it happened. So, the error creeps in on the file 1046PST-K@20190421, which is directly calculated from the file 1046PST-B2@20190421, (and 1046PST-P@20190421 which is okay too.) Looking at that file:

GRASS 7.4.2 (solar):~/spatial-cimis/gdb/solar/20190421 > r.info 1046PST-K@20190421
 +----------------------------------------------------------------------------+
 | Map:      1046PST-K@20190421             Date: Mon Apr 22 17:23:19 2019    |
 | Mapset:   20190421                       Login of Creator: cimis           |
 | Location: solar                                                            |
 | DataBase: /data/quinn/spatial-cimis/gdb                                    |
 | Title:    1046PST-K                                                        |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: 0               |
 |   Data Type:    DCELL                                                      |
 |   Rows:         2560                                                       |
 |   Columns:      2304                                                       |
 |   Total Cells:  5898240                                                    |
 |        Projection: Albers Equal Area                                       |
 |            N:     512000    S:    -768000   Res:   500                     |
 |            E:     640000    W:    -512000   Res:   500                     |
 |   Range of data:    min = -nan  max = -nan                                 |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.mapcalc                                                  |
 |                                                                            |
 |   Comments:                                                                |
 |    if((--2147483648 - 1046PST-B2) / (--2147483648 - 1046PST-P) > 0.2,      |
 |    min((--2147483648 - 1046PST-B2) / (--2147483648 - 1046PST-P), 1.09),    |
 |    min(0.2, 1.667 * ((--2147483648 - 1046PST-B2) / (--2147483648 -         |
 |    1046PST-P)) ^ 2 + 0.333 * ((--2147483648 - 1046PST-B2) /                |
 |    (--2147483648 - 1046PST-P)) + 0.0667))                                  |
 |                                                                            |
 +----------------------------------------------------------------------------+

We see that there is this questionable number --2147483648 in the calculation. Since that big number gets squared, that's where the problem is. Now, if we look at the calculation of K we see that what it really uses is the raster max and min, and if we look at that file

cat gdb/solar/20190421/etc/max/1046PST-B2  
min=-2147483648
max=-2147483648

Well that's wrong! A little digression. Why are these max and min values not just the max and min from the raster itself?

r.info -r 1046PST-B2@20190421
min=1386.24
max=30686.03

Because in the GOES15 days, you would get these data spikes of one pixel with huge values, so we couldn't just take that max number. So, you will see from the max and min code, we get those from a neighborhood of values. If you run that specific code, you get fine results.

r.neighbors --overwrite input=1046PST-B2@20190421 output=_maxcalc size=5 method=average
r.info -r _maxcalc
min=1776.01123046875
max=27917.515859375

But because we don't save that calculation, the bottom line is that I don't know why that was originally not calculated correctly. We can quickly check the other data,

for i in gdb/solar/20190421/etc/max/*; do cat $i | sed -e "s|.*=\(.*\)\$|\1 $i|"; done | sort -n | less
-2147483648 etc/max/1046PST-B2
-2147483648 etc/max/1046PST-B2
-265.664798517227 etc/max/0611PST-B2

So that looks like the only bad calculation, but look! we do get some radiance values less than 0 for the early morning. Something to think about.

The fix

You should be able to just remove that file, and remake the solar.

rm solar/20190421/etc/max/1046PST-B2
g.mapset 20190421
# If you run the make below with the -n flag, you will see it only calculates 
# the incremental Gi for 1046 and the updates the final values.
make --directory=~/spatial-cimis/g.cimis/etc -f solar.mk solar 

Preventing in the future

I'm not sure it's worth putting in a guard for this, since we can't replicate what happened. I can't really come up with an idea of why we got that failure.

[qjhart]

@gjscheer-ucd If this is all replicable, please close the issue. (And Delete this note :)

[gjscheer-ucd]

Good info Quinn. My alert filter only searches for integer zero and NaN values. I'll need to include negative max values for B2 data.

As for why it returned that data I suspect a parallel job for that day interfered. I re-imported the raw CA data and the solar calculation went through fine AKAIK.