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.
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