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

20030509: Unidata binary of nwx core dumps with surface obs

Robert,

I've found that if no files are found the first time, then the second time
when using the same data set, I do get the messages you mentioned.
I fixed my taf problem with the appropriate file name. I'm in the
process of rolling in 5.6.K changes, and will see if we can get our 
purify license back to check the code more thoroughly (at this point,
we no longer have a licensed environment).

One other thought would be if your pqact was running behind in
getting the metars decoder out to the YYYYMMDD_sao.gem file.
You would notice that if you frequently went to plot a surface chart
and had very few obs for the current hour- which is possible if IO is 
getting slow. If that were the case, the "1" hour choice would probably fail,
but ypu would expect to see something if you went to "6" or "12" hours
(eg the file and paths are all correct, but the data just isn't
up to date in the file that nwx is looking at).

Steve


>From: Robert Mullenax <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200305091558.h49Fwv7U027362

>> 
>
>Yes I am having the same issue with tafs, but my surface files are named 
>with the standard YYYYMMDD_sao.gem format.
>
>I don't know what's involved but I wonder if it would be easier to make
>the changes needed to compile GEMPAK with gcc/g77. I suspect this is a Sun
>compiler issue..although I believe we are patched up pretty well.  
>
>As I said I just copied over the Unidata binary of NWX as this has worked
>in the past...NWX won't work on x86 or SPARC if I compile it..but I haven't
>tried running the entire Unidata binary dist.
>
>I might can try that tonight..although as a permanent solution I would rather
>compile as I have found that some optimization speeds up things for us and I d
> o
>have some local mods.  In the past I have compiled with/without optimization
>and still nwx is broken when it comes to surface obs. 
>
>Thanks,
>Robert
>
>> Robert,
>> 
>> I haven't duplicated your problem with SFC_HRLY yet....but I did find a prob
> lem
>> with the TAFS_DEC section where the files from the dctaf action are being na
> med
>> YYYYMMDDHH_taf.gem and the nwx program is always expecting YYYYMMDD(extensio
> n)
>> names. So, I thought I'd verify once again that your surface files are name
>> YYYYMMDD_sao.gem (and don't have the hour). This also means that if you are
>> using the dctaf decoder and the suggested file naming, you should have the s
> ame
>> problem with those reports.
>> 
>> Basically, the first call to the directory returns an error when the file na
> mes
>> aren't of the expected format. The second call using the same master.tbl cat
> egory
>> will skip the directory scanning for the sake of speed since the category is
>> the same- but doesn't know that the directory was empty.
>> 
>> Steve Chiswell
>> 
>> 
>> 
>> 
>> 
>> 
>> >From: Robert Mullenax <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200305062023.h46KNT7U020274
>> 
>> >> 
>> >
>> >Sorry, I should know better than to type something from memory.  You are co
> rre
>> > ct.
>> >I have exactly what you have there.  Nothing has been modified.
>> >
>> >Robert
>> >> Robert,
>> >> 
>> >> I'm trying to follow your steps below, but you don't mention the same 
>> >> categories that I have. Lets verify:
>> >> 
>> >> 1) Open nwx
>> >> 2) Click on "Observed Data", you said "surface obs" which is not in my di
> st
>> >> 3) Click on "Surface Hourlies"
>> >> 4) Set time range
>> >> 5) Click on station
>> >> 
>> >> The master.tbl entry for SFC_HRLY is:
>> >> SFC_HRLY     sfstns.tbl   O $GEMDATA/surface                         _sao
> .ge
>> > m
>> >> 
>> >> That is expecting files named yyyymmdd_sao.gem in $GEMDATA/surface.
>> >> If thats not what you have, then lets see what master.tbl entries you are
>  us
>> > ing.
>> >> 
>> >> Steve Chiswell
>> >> Unidata User Support
>> >> 
>> >> 
>> >> 
>> >> 
>> >> >From: Unidata Support <address@hidden>
>> >> >Organization: UCAR/Unidata
>> >> 
>> >> >
>> >> >Robert,
>> >> >
>> >> >The mangling of the string below with the "dm/gempak/surface"
>> >> >getting tacked on seems to indicate either a string that
>> >> >is not properly null terminated, or is exceeding the length.
>> >> >The fact that certain versions usually work is probably
>> >> >a side affect of optimization in the compiler (less optimization
>> >> >sometimes keeps variables separated in memory space so that not
>> >> >crashing is merely fortuitous).
>> >> >
>> >> >I can look at the code and see if there is a memory problem.
>> >> >
>> >> >Steve Chiswell
>> >> >Unidata User Support
>> >> >
>> >> >
>> >> >
>> >> >>From: Robert Mullenax <address@hidden>
>> >> >>Organization: UCAR/Unidata
>> >> >>Keywords: 200305040336.h443aI7U004383
>> >> >
>> >> >>
>> >> >>In the past I have had trouble with locally built (Sun compilers SPARC 
> and
>> >  x8
>> >> > 6
>> >> >>  Solaris)
>> >> >>versions of nwx core dumping while trying to read surface obs.  I exper
> ien
>> > ced
>> >> >>the aame thing on x86 (wxmcidas.nsbf.nasa.gov) with 5.6j, however, this
>  ti
>> > me
>> >> >>my usual fix of getting the Unidata binary for nwx didn't work either. 
>  It
>> >  al
>> >> > s
>> >> >> o core
>> >> >>dumps.
>> >> >>
>> >> >>I open nwx, select surface obs, click on one station and get station no
> t f
>> > oun
>> >> > d
>> >> >>  (even
>> >> >>though it is there and sflist verifies that).  If I do nothing else all
>  is
>> >  fi
>> >> > n
>> >> >> e..
>> >> >>if I select another station then I get these errors writen to the termi
> nal
>> > :
>> >> >>
>> >> >>/export/home/gempak% nwx
>> >> >>Resource File:  /export/home/gempak/GEMPAK/resource/Nwx
>> >> >> [FL -1]  Cannot open file /var/data/ldm/gempak/surface/dm/gempak/surfa
> ce.
>> >> >> [SF -2]  File /var/data/ldm/gempak/surface/dm/gempak/surface could not
>  be
>> >  op
>> >> > e
>> >> >> ned.
>> >> >>Segmentation fault (core dumped)
>> >> >>
>> >> >>I have verified that Gemenviron and ~/gempak/nwx/master.tbl are correct
> , t
>> > hat
>> >> >  
>> >> >> the
>> >> >>data path is /var/data/ldm/gempak/surface...so it's somehow mangling
>> >> >>the path.
>> >> >>
>> >> >>I could go back and use an older version of nwx, but we find some of th
> e n
>> > ew 
>> >> > f
>> >> >> eatures in
>> >> >>nwx 5.6j to be useful and nice.
>> >> >>
>> >> >>Thanks,
>> >> >>Robert
>> >> >>
>> >> >
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8643                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service              http://my.unidata.ucar.edu/content/suppo
> rt 
>> >> *************************************************************************
> ***
>> >
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ****************************************************************************
>
>