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

[Datastream #QOK-427508]: NPS: New "manager", Date problem

Hi,

re:
> I am a meteorologist at the Naval
> Postgraduate School in Monterey, California. Our department's long-time
> (since mid-1990s) data/software/network expert, and Unidata guru
> has retired and visits campus very infrequently. While the
> department is in search of a replacement, I have been tasked to
> help act as an interim manager.

OK, we understand and are here to help if we are able.

re:
> To get my feet wet, I am trying to fix a problem with the date that is
> appearing on gridded data ... see attached screenshot.  GOES-15 imagery
> dates are fine.

Which imagery were you trying to display in Garp?

re:
> Perhaps you could point me in the correct direction to tackle this
> problem.  I suppose I may need to get set up with a Unidata account?

You do not need a Unidata account for support, and you won't need one
to download a new version of GEMPAK as that is hosted on GitHub.  You will
need a Unidata account if you wish to download a variety of the other
software packages that we make available.

re:
> Thanks for any help you can provide,

Some questions:

- what satellite image were you trying to display in Garp?

  The screen shot you sent did not have any satellite imagery
  component in it, so I can't tell what was attempted to be
  displayed.

- which IDD feeds are you currently REQUESTing, and what is the name
  of your machine that is running the LDM to REQUEST those feeds?

  I checked our real-time statistics page, and it is not obvious to me
  if your LDM is sending us statistics, so I can not figure this out
  for myself.  It is possible that your LDM configuration is not setup
  to report real-time statistics, and it is equally likely that the
  NPS network is blocking the connection that is designed to report
  real-time statistics.

  FYI: reporting real-time statistics is controlled by an EXEC action
  in the LDM configuration file, ~ldm/etc/ldmd.conf.  The entry will
  look more or less like:

  EXEC   "rtstats -h rtstats.unidata.ucar.edu"

  If the line is commented out ('#' mark as the first character), your
  LDM is not sending us real-time statistics.  If it is not commented,
  it should mean that the connection that 'rtstats' is trying to make
  back to us (rtstats.unidata.ucar.edu) is being blocked somewhere at
  the NPS.

- are you or someone else at the NPS subscribed to the address@hidden
  email list?

  It is important that someone there be subscribed to the list so that
  you will be aware of changes to datastreams, outages, etc.  Given that
  you are an active GEMPAK users, tt is also important that someone there
  be subscribed to the address@hidden email list.

  You can (un)subscribe to any email list that we maintain online at:

  https://www.unidata.ucar.edu/support/index.html#mailinglists

  One of the most important messages sent recently to the ldm-users list
  was about the impending change to the NIMAGE datastream.  This is
  particularly important for sites that are REQUESTing the NIMAGE
  feed with a simple ".*" pattern (i.e., everything) as the volume
  in the feed will increase on the order of 70 fold.

  For sites that are currently REQUESTing everything in the NIMAGE feed,
  we are suggesting that they change their REQUEST to something like:

  REQUEST  NIMAGE "satz" <upstream feed host>

  in advance of the change in the NIMAGE datastream so that they won't
  get a flood of new data that they either do not want or are not setup
  to handle.

  NB: anytime a change is made in the LDM configuration file,
  ~ldm/etc/ldmd.conf (like changing REQUEST(s), etc.), the LDM
  must be stopped and restarted for the change(s) to take effect.

- what version of GEMPAK are you running?

  I ask because older versions of GEMPAK (all previous to the current
  release) can NOT display imagery in netCDF4 format, and that is the
  format of the GOES-16/17 imagery, reconstituted from the tiles
  (pieces) that are sent out in the NOAAPort SBN and then relayed in
  the NOTHER feed, that will be added to the NIMAGE feed next week.

  Again, the impact on the content of the NIMAGE feed will be significant:
  The data volume will increase from an average of 100 MB/hr to just shy of 7
  GB/hr, a 70-fold increase.  This increase will have impacts on network use,
  and they will most likely require that the local LDM queue be made larger.

Comment about Garp:

Since Garp is no longer supported (it was moved to community support status
a couple/few years ago), it is unknown, but doubtful, if it will be able to
display the GOES-16/17 imagery that will be added to the NIMAGE feed. I could
be wrong about this, but this is something that we have not/will not tested
internally, so I feel it is important to advise you of the change.

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: QOK-427508
Department: Support Datastream
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.