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

[GEMPAK #NSD-970726]: NSHARP Problem in GEMPAK5.9.4

Brent,

This may be a problem that is already fixed in the 5.10.1 distribution.
I have attached a Linux64 binary if you can run it compiled under FC5
(since you mentioned you could run a 5.9.3 binary....wasn't sure if
you meant one you donloaded from UPC, or one you had previously built).
Note that with 5.9.4 and later, I am provide separate Linux 32 bit and
Linux64 64 bit binaries (and $NA_OS trees).

Can you give this a try?

Steve Chiswell
Unidata User Support



> Steve,
> 
> 
> 
> I have noticed some strange problems loading model soundings with NSHARP
> in GEMPAK5.9.4 (compiled from source on both Intel Linux and AMD Linux
> x86_64).  By model soundings, I mean soundings generated from the
> gridded data files, not the BUFR point soundings produced at NCEP.  I
> have been doing a bunch of tests this morning to see if I can narrow the
> set of problems down.  Here goes:
> 
> 
> 
> 1.    After starting NSHARP, the first time I try to load a GFS model
> sounding, upon hitting the "OK" button after time and location
> selection, I get a blank Skew-T plot and the "Show Data" shows no data.
> However, if I then click on Load>Model Soundings again and leave all of
> my original time and location selections alone and simply hit "OK"
> again, it then properly loads and plots the Skew-T.  The same behavior
> occurs for UKMET grids (blank on the first attempt, second and
> subsequent attempts are fine).  Interestingly enough, the NAM40 and
> RUC20 soundings (in fact, all of the non-global model data sets we have)
> work fine on the first attempt.  In case it matters, the GFS data are
> the 1x1 degree GRIB-2 data decoded using dcgrib2 and stored in files
> named YYYYMMDDHHfFFF_gfs.gem, and the UKMET data is the standard
> NOAAPORT data feed configured in the default manner.  The NAM40 is the
> GRIB-2 grid 212 data retrieved from NCEP and passed into dcgrib2, stored
> as YYYYYMMDDHHfFFF_nam40.gem, and the RUC20 is also GRIB-2 data from
> NCEP.  I also have gridded LAPS analyses in GEMPAK format, and sounding
> extraction works fine on the first attempt from those as well.  So, it
> seems like the blank first attempt problem is limited to global data
> sets, although I only have two global data sets to test on.
> 
> 
> 
> 2.    After loading any model sounding successfully, any attempt to
> load a sounding from a different model will fail.  NSHARP doesn't crash,
> but it doesn't replace the previously plotted data, although it does
> change the model name and time in the header on the plot.  From this
> point on, you cannot successfully plot any sounding from a different
> model.  You can however switch back to the first model originally
> plotted and then select different times or points, and it will properly
> update.  You can also switch over to observed soundings successfully.
> But even after switching to an observed sounding, if you try to go back
> to model soundings, the only ones that will work are those from the same
> model set selected the first time you successfully plotted a model
> sounding.  There is one caveat to this I just found.  I can successfully
> switch between models that have identical navigation information.  For
> our LAPS analysis domains mentioned in item 1, we have corresponding
> forecast grids from our locally run WRF model system.  The LAPS and WRF
> navigation grids are identical, but they are stored in different files
> as different models.  In spite of them being different "models" from the
> NSHARP perspective, I am able to switch back and forth between them.
> But, I cannot switch from one of those back to any other model that has
> different navigation.
> 
> 
> 
> 3.    No errors are generated on the console in any of these cases,
> even when running nsharp by hand outside of the ntl toolbar.
> 
> 
> 
> I can run the 5.9.3 nsharp binary with the tables in my 5.9.4
> distribution and these problems go away.  So, it seems to be isolated to
> something about how the 5.9.4 nsharp program itself works or maybe a new
> library dependency.  In particular, it seems to be related to the
> navigation/projection information of the grids, almost like a common
> block is being populated on the initial load of a model sounding and
> then it is never able to be properly re-initialized.
> 
> 
> 
> Let me know if you need me to try anything specific or need to know
> anything about my configuration.  I would be curious to know if others
> have observed this behavior.
> 
> 
> 
> Best regards,
> 
> Brent
> 
> 
> 
> ------------------------------------------------------------------------
> ---------
> 
> Brent Shaw
> 
> Scientific Technologist
> 
> Weathernews, Inc.
> 
> Direct:  +01-405-310-2851
> 
> Mobile: +01-405-740-9554
> 
> Fax: +01-405-310-2801
> 
> address@hidden
> 
> 
> 
> http://weathernews.com
> 
> Always WITH You!
> 
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: NSD-970726
Department: Support GEMPAK
Priority: Normal
Status: Closed