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

[Datastream #IZJ-689237]: Additional Datafeeds

Hi Jeff,

re:
> I like to just use binary versions on personal stuff, out of laziness. On 
> this I thought
> I better build it from the ground up though, since it's a little more 
> important than a web
> browser or some such thing. :-)

I agree ;-)

re: Why the dcacft, dcmetr and dcmsfc decoders were producing
 bad output files is now a bigger mystery than it was before.\
 
> That doesn't sound good...

Right.  We are not getting support inquiries dealing with decoding issues from 
other sites running
5.11.1 except a couple whose problems went away when they built from source.

re: monitor the situation
> I did check it out.  The same types of holes are present. An example would be 
> when I
> go into Garp > View > Model > Plan Projection and choose GFS thinned.  I then 
> pick the
> Convective dropdown, choose some times, and hit Display and get this:
> 
> GEMPAK: [DG -7]  Input grid CINS ^081017/1200F000 @0 %NONE in SM9S cannot be 
> found.
> GEMPAK: [DG -7]  Input grid CINS ^081017/1200F006 @0 %NONE in SM9S cannot be 
> found.
> GEMPAK: [DG -7]  Input grid CINS ^081017/1200F012 @0 %NONE in SM9S cannot be 
> found.
> GEMPAK: [DG -7]  Input grid CINS ^081017/1200F018 @0 %NONE in SM9S cannot be 
> found.
> GEMPAK: [DG -7]  Input grid CINS ^081017/1200F024 @0 %NONE in SM9S cannot be 
> found.
> 
> Along with blank frames in Garp.  This is very similar to what I was seeing 
> before and what
> I see in other places.

Not being a GEMPAK guy, I have little to offer here other than it might be 
useful to use
NMAP2 and see if the same kind of holes are showing up in it.  If they are not, 
then
the problem is in Garp.  If they are, then the problem is in the decoding.

> The main place that this occurs (or at least the place that my Chair is 
> wanting fixed) is
> in the Model Plan View, in the scalar dropdown choices.  Most of the General 
> choices are
> all right, but everything else has missing input grids or no grids at all.
> 
> Any ideas?

No sorry.  I will have to get our GEMPAK person involved in this.

re: McIDAS installation/update
> I would be interested in that, once the datafeed issue is solved 
> satisfactorily.

Here's the thing: your CONDUIT and HDS data ingestion is showing large 
latencies.
If your upstream feed host's queue is not large enough to have the data you are 
trying
to get over the period of time that you are now taking to get it, then you will 
miss
products. This seems like a real possibility for your CONDUIT ingest and less a
possibility for your HDS ingest.

Let's try a test:

- let's split the CONDUIT ingest into 10ths:

change:

request CONDUIT "([09]$)" idd.unl.edu
request CONDUIT "([18]$)" idd.unl.edu
request CONDUIT "([27]$)" idd.unl.edu
request CONDUIT "([36]$)" idd.unl.edu
request CONDUIT "([45]$)" idd.unl.edu

to:

request CONDUIT "0$" idd.unl.edu
request CONDUIT "1$" idd.unl.edu
request CONDUIT "2$" idd.unl.edu
request CONDUIT "3$" idd.unl.edu
request CONDUIT "4$" idd.unl.edu
request CONDUIT "5$" idd.unl.edu
request CONDUIT "6$" idd.unl.edu
request CONDUIT "7$" idd.unl.edu
request CONDUIT "8$" idd.unl.edu
request CONDUIT "9$" idd.unl.edu

> I got the go-ahead to "remove" the existing data directory and start over.  
> What do you think?

Can't hurt...

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