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

[Datastream #IZJ-689237]: Additional Datafeeds

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [Datastream #IZJ-689237]: Additional Datafeeds
  • Date: Tue, 04 Nov 2008 12:44:14 -0700
Hi Jeff,

re:
> Thanks for responding so quickly!  It's nice to have you back. :-)

When workshops are in progress, our ability to respond to support inquiries
is diminished...

re: try using a pre-compiled binary for your GEMPAK decoders
> I just substituted that this morning, so I haven't seen anymore data
> come across to test it.  Is there a way to run data through it now,
> rather than waiting for the next scheduled round?

There is, but it wouldn't be testing the same set of circumstances.

Just in case:  all GEMPAK decoders can be run from the Unix command line.  If
you have GRIB/GRIB2 messages saved to disk that you want to use to test dcgrib2,
you will need to:

- define the GEMPAK environment (i.e., source ~gempak/NAWIPS/Gemenviron)

- cat the product to the decoder while specifying the various command line
  values that dcgrib2 requires (see pqact.gempak_decoders pattern-actions for
  multiple examples)

re: moving GEMPAK tables should not make any difference

> I've already switched the tables/grid directory out, so I'll leave it,
> for now, just in case.

OK, this will not hurt (as long as the correct path reference is used in
the GEMPAK decode actions.

re: disabling IPv6 reference
http://blog.taragana.com/index.php/archive/how-to-disable-ipv6-on-fedora-linux-why/

> I'll look into this.  It can't hurt...

I did this on a hunch when working with the site representative last Friday.
His situation was different than yours in that HDS products were shown to be
received by 'ldmadmin watch -f HDS', but were _not_ seen by 'notifyme -vl- -f 
HDS'
or by 'pqcat -vl- -f HDS -o 3600 > /dev/null).  This situation made absolutely
NO sense to us (Steve Emmerson, the LDM developer and me), so we were down to 
trying
desperate actions :-)

re: changing the system clock
> Would that make a difference?

It shouldn't, but we are grasping at straws here...

> I was thinking that you had changed that?

No.  All I changed was 'ldm's crontab entries so that the various actions 
(e.g., scouring
and file rotation) would run at the desired times (just after 0Z).

> Thanks again.

No worries.

Question:

- do you have 'root' access?
- can you give me 'gempak' access (or, did you already do that... things are a 
bit hazy)?

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