[LDM #HHO-369434]: GOES-15 data stopped

Hi Mike,

re:
> I was fooled as usual:
> 
> This is how I'm getting GOES-15 on titan, where I see I have data:
> request         NIMAGE  "satz"  iddb.unidata.ucar.edu

OK.  You do realize that this REQUEST is _not_ for imagery in the
UNIWISC feed, correct?  Your inquiry said:

"Goes-15 imagery stopped coming through UNIWISC feed"

The real-time stats links I sent you were all for the UNIWISC feed.
I did, however, check to make sure that the GOES-15 GINI imagery
that originates in NOAAPort have been available over the past couple
of days.

re:
> E.G. "satz/ch2/GOES-15/3.9/20190925 1645/WEST-CONUS/4km/
> 
> But on vulcan I have:
> 
> [ldm@vulcan etc]$ more ldmd.conf | grep UNIWISC
> request UNIWISC ".*" idd.unidata.ucar.edu
> 
> and no satz:
> [ldm@vulcan etc]$ more ldmd.conf | grep NIMAGE
> (removed exec entries)
> REQUEST NIMAGE  "GOES"  idd.unidata.ucar.edu

The regular expression "GOES" will match all of the imagery
available in the revamped NIMAGE feed, and that includes GOES-16,
GOES-17 and the GOES-15 imagery in GINI format:

Example Product IDs:

GINI

satz/ch2/GOES-15/IR/20190925 1745/AK-NATIONAL/8km/ TIGB02 KNES 251745

netCDF4

/data/ldm/pub/native/satellite/GOES/GOES17/Products/CloudAndMoistureImagery/Mesoscale-2/Channel09/20190925/OR_ABI-L2-CMIPM2-M6C09_G17_s20192681817570_e20192681817570_c20192681817570.nc

re:
> Our systems restarted on Friday 9/20/2019, so I suspect there were edits to
> ldmd.conf that had never been implemented.  Hmm still a bit of a head
> scratcher, because for sure the Goes-15 data was coming in on vulcan.

Vulcan is receiving all of the NIMAGE imagery while titan is only receiving
the GINI imagery:

vulcan NIMAGE volume
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NIMAGE+vulcan.science.sjsu.edu

titan NIMAGE volume
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NIMAGE+titan.met.sjsu.edu

The REQUEST for NIMAGE imagery on titan was scaled back to the original
NIMAGE content mainly since titan's LDM queue is not large enough.

Speaking of memory for titan...

We really have to apologize for not sending you the spare memory we
have.  Our tardiness basically boils down to being overloaded
and from the original intent to put the memory into a machine to
test it before we ship it.  Mike and I just talked about the need
to test, and we decided to leave that decision up to you.  So:

- are you OK with us sending you memory without testing?

  NB: it was all working when removed from machines, but that was
  some time ago, so there is a possibility that one or more
  DIMMs will not work

OR

- do you want us to test the memory before we send it?

Again, many apologies for the delay!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: HHO-369434
Department: Support IDD
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.