CIMIS GOES R zero data alert

A CIMIS GOES-R Zero alert comes when bad data gets interjected into the goes16 processing. These data need to be removed from the solar mapset for proper processing.

This might also be identified in the Users' Guide

Notices

Notices will show up in the goes-R slack and as pushover notifications. One discovered, you can look at all status at: https://status.cstars.ucdavis.edu/

There is a specific status file for this problem at: http://cimis-goes-r.cstars.ucdavis.edu/cimis/status/band-2

Recovery procedure

Once a bad data set is added, that particular instantaneous radiation ????-Gi data is corrupt, and therefore, all subsequent ????-G are bad as well. You need to remove the offending time, and all subsequent ????_G files, and then you can catch up again with a new solar command for the day as well. Below is an example of a typical recovery.

grass ~/gdb/solar/cimis  # Interactive mode start in cimis mapset for .bashrc goodness
time=0830PST
date=20191004
g.mapset ${date}         # Go to bad day
g.remove -f type=rast pattern=${time}-*
for i in $(g.list pattern=*-G type=rast); do 
  if [[ $i > $time ]]; then 
    g.remove type=rast name=$i
  fi; 
done
make --directory=~/spatial-cimis/g.cimis/etc/ -f solar.mk solar $date

After that, you can reset the zero monitor with

~/bin/cimis-solar-data-check.sh 2>&1 > ~/logs/cimis-solar-data-check.$(date --iso).log ;cp ~/logs/cimis-solar-data-check.$(date --iso).log ~/gdb/www/cimis/status/band-2

This is also in the cronjob, and can get reset there.

Examples

Multiple Dates around 2019-10-01 thru 2019-10-?? had consistent zero alerts for the 0830PST-B2 images. It's not consistent what's happening, but here's an example showing the dropout