[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #OAO-858724]: No GOES VIS imagery

Hi Chris,

re:
> Thanks for taking the time to spell out the steps.

One of the biggest reasons for the detail is so that readers of the
transaction found through web searches (all responses are HTMLized and
then made available to web crawlers so that one can find questions and
answers through web searches) will have enough detail to allow other
users to replicate the steps in their own troubleshooting.

re:
> First thing I noted
> right away is that the first feed listed in our ldmd.conf file is not
> active.  The second feed (which I assume is who we were feeding from all
> along) was not sending any VIS products.

Hmm... This is very interesting.  I think that it is very strange that
a site that is ingesting the Unidata-Wisconsin imagery (IDD feedtype
UNIWISC aka MCIDAS) would choose to not get the VIS images.  Can you
forward along the name of the upstream that does not have the VIS images?

re:
> The third feed is, and so I made
> this the primary (by listing it first) and restarted the LDM.

Just so you know, the ordering of REQUEST lines in one's ~ldm/etc/ldmd.conf
file has no effect on which feed will be the primary feeder.  The speed
at which products are relayed is the governing factor in determining
primary versus secondary, and that hierarchy can change dynamically through
differing network congestion to the different upstreams.

re:
> I verified that none of the VIS files are being written to the disk.

Do you see anything relevant in the log file specified in your pattern-action
file action:

# Vis (0.65 um) - Relaxed to account for channel change 3/2014 cch
UNIWISC ^pnga2area Q. (U[^ACXY13]) (.*) (.*)_IMG (0.6[235])um (.*) (........) 
(....)
    PIPE -close
    pnga2area -vl logs/ldm-mcidas.log
    -a etc/SATANNOT
    -b etc/SATBAND
     data/ldm/gempak/images/sat/\3/\5/VIS/VIS_\6_\7

The log file specified is ~ldm/logs/ldm-mcidas.log.

re:
> Here's what I get when I check to see if the VIS products are being
> processed properly:
> 
> (blizzard) /local/ldm/data/gempak/images/sat/GOES-13/4km/VIS > notifyme -vl- 
> -f UNIWISC -h vortex.esc.brockport.edu -o 1000000 -p "^pnga2area Q. 
> (U[^ACXY13]) (.*) (.*)_IMG (0.6[235])um (.*) (........) (....)"
> Aug 01 23:32:58 notifyme[20136] NOTE: Starting Up: vortex.esc.brockport.edu: 
> 20140721094618.334 TS_ENDT {{UNIWISC,  "^pnga2area Q. (U[^ACXY13]) (.*) 
> (.*)_IMG (0.6[235])um (.*) (........) (....)"}}
> Aug 01 23:32:58 notifyme[20136] NOTE: LDM-5 desired product-class: 
> 20140721094618.334 TS_ENDT {{UNIWISC,  "^pnga2area Q. (U[^ACXY13]) (.*) 
> (.*)_IMG (0.6[235])um (.*) (........) (....)"}}
> Aug 01 23:32:58 notifyme[20136] INFO: Resolving vortex.esc.brockport.edu to 
> 137.21.88.151 took 0.001447 seconds
> Aug 01 23:32:58 notifyme[20136] NOTE: NOTIFYME(vortex.esc.brockport.edu): OK
> Aug 01 23:33:04 notifyme[20136] INFO:  1492016 20140801221145.088 UNIWISC 000 
>  pnga2area Q1 U9 122 GOES-15_IMG 0.62um 4km 20140801 2200
> Aug 01 23:33:19 notifyme[20136] INFO:  2069941 20140801223115.596 UNIWISC 000 
>  pnga2area Q1 UV 142 GOES-13_IMG 0.63um 4km 20140801 2215
> Aug 01 23:33:39 notifyme[20136] INFO:  1489021 20140801224145.730 UNIWISC 000 
>  pnga2area Q3 U9 122 GOES-15_IMG 0.62um 4km 20140801 2230
> Aug 01 23:33:54 notifyme[20136] INFO:  1917788 20140801230121.330 UNIWISC 000 
>  pnga2area Q3 UV 142 GOES-13_IMG 0.63um 4km 20140801 2245
> Aug 01 23:33:59 notifyme[20136] INFO:  1491081 20140801231146.529 UNIWISC 000 
>  pnga2area Q1 U9 123 GOES-15_IMG 0.62um 4km 20140801 2300
> Aug 01 23:34:12 notifyme[20136] INFO:  1755067 20140801233127.030 UNIWISC 000 
>  pnga2area Q1 UV 143 GOES-13_IMG 0.63um 4km 20140801 2315
> 
> This looks normal, yes?

Yes, this looks completely normal.  The counterpart to monitoring the 
availability
of products on the upstream feed site (your listing) is the monitoring of 
receipt
of those products on your machine:

notifyme -vl- -f UNIWISC -o 1000000 -p "^pnga2area Q. (U[^ACXY13]) (.*) 
(.*)_IMG (0.6[235])um (.*) (........) (....)"

When the '-h' flag is not specified, the 'notifyme' invocation will interrogate 
the
LDM on the localhost.

If you are seeing the receipt of the products in question (product codes U9, 
UV, EV)
in the 'notifyme' invocation that is interrogating the localhost, the next
step is to look to see what, if any, problems are indicated in the log output
for the process ('pnga2area' in this case).

What I would do is have the 'notifyme' invocation running in one window and
a tailing 'less' of the log file in another window.  This way you could see
the log messages being written as the products are being received.  Of
course, you would have to be watching the receipt of products "live".

re:
> I am probably missing something silly, but still no VIS being written to
> disk.

Well, if you are missing something silly, then so am I!

re:
Suggestions?

My first suggestion is to do the test I just outlined above ('notifyme' and 
following
'less').  If nothing obvious is indicated, I would be happy to login to your
machine and do some more detailed investigations.  If you decide that you want
me to login, please either call me with the credentials (W: 303.497.8642,
H: 303.258.0906) or send me an email with the password for the 'ldm' account
with _NO_ mention that it is for the 'ldm' account and _NO_ mention of the
machine for which it applies to.

Aside:

I just tried to run 'notifyme' from my Unidata workstation to your LDM machine
(blizzard), but the connection was never established.  This indicates either
that you do not have an ALLOW for machines in the unidata.ucar.edu domain
(this is included in the default ldmd.conf file included with the LDM), or
there is a firewall that is not allowing incoming traffic to port 388 on
your machine (the firewall could be running on your machine and/or in the
campus security perimeter).  Allowing us to contact your LDM would help
us help you in troubleshooting problems such as the one you are facing
currently.

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: OAO-858724
Department: Support IDD
Priority: Normal
Status: Closed