20001110: 20001110: 20001110: 20001023: radar problems in nmap/garp - gempak5.6

Bryan, 


The previoius version may be a problem with the string length to files.
For directories with lots of files, or long path names to the files, the
resultant strings for times passed back could overflow the allocated space.
This should be corrected in the current release.

The first instance is probably a problem with the parsing of the filename
into the date pieces.

Let me know if you encounter any problems with the current version and
file naming.

Steve Chiswell



>From: "Bryan G. White" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200011102144.eAALi1D15230

>Thank you.  radar is now working in nmap and garp.
>
>Two side notes:
>  If I use format of BREF1200011072010, garp dies a violent death
>  sometimes.  Haven't noticed a pattern on when it dies. Sometimes
>  it works sometimes it doesn't.

> 
>  If I use the format of BREF1_20001107_2010 in an older version of
>  garp it dies a violent death if I had viewed other data first, ie models.
>
>Bryan
>
>
>
>
>> 
>> Ok...This appears to be what I mentioned the first time.
>> Your actual radar product:
>> /cirp/data/radar/MTX/BREF1/MTXBREF1200011072010
>> 
>> try changing this to:
>> /cirp/data/radar/MTX/BREF1/BREF1_20001107_2010
>> 
>> You should do this for all files in the directory, since if you don't Garp w
> ill
>> crash when trying to make a time out of the filename for anything that doesn
> 't fit.
>> It probably will be trying to create a number out of some part of the 
>> MTXBREF name.
>> 
>> For nmap, it turns out that the BREF1/BREF1_* is important. That is, if you 
> have:
>> BREF1/MTXBREF1_YYYYMMDD_HHMM, then the first part of the file name befor the
>  '_'
>> doesn't match that of the directory, so it won't display anything in the tim
> e menu.
>> 
>> The pqact.conf actions I have assume the BREF1_20001107_2010 file names,
>> as do the $GEMTBL/config/datatype.tbl and $GARPHOME/config/Garp_defaults
>> entries that I sent out.
>> 
>> Steve Chiswell
>> 
>> 
>> 
>> 
>> >From: "Bryan G. White" <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200011101950.eAAJoqD11551
>> 
>> >Understandable,  I'm mixed up so you are probably mixed up reading
>> >my mix up which is mixed up.......
>> >
>> >From Garp_defaults:
>> >
>> >RADDIR          : /cirp/data/radar
>> >nids            : $(RADDIR)
>> >
>> >nidsT           : $(nids)/%(site)/%(product)/*@(YYYYMMDDHHNN)
>> >nowradT         : $(nowrad)/%(product)/*@(YYYYMMDDHHNN)
>> >
>> >From Nmap datatype.tbl:
>> >
>> >RAD          $RAD                      *YYYYMMDDHHNN             CAT_IMG  S
> CAT
>> > _NIL
>> >
>> >From Gemenviron:
>> >
>> >setenv RAD           /cirp/data/radar
>> >
>> >
>> >Actual Path name of a radar product:
>> >/cirp/data/radar/MTX/BREF1/MTXBREF1200011072010
>> >
>> >
>> >
>> >
>> >
>> >> Can you elaborate on this:
>> >> 
>> >> > >Here is an example of what a radar file is named:
>> >> > >MTXVEL1200010231525
>> >> 
>> >> I'm having trouble matching that with what you have below.
>> >> 
>> >> 
>> >> In Garp_defaults,
>> >> nids            : $(RADDIR)/NIDS
>> >> 
>> >> where RADDIR is defined at the top of the file as $RAD.
>> >> The structure is the same as before.
>> >> 
>> >> Steve Chiswell
>> >> >From: "Bryan G. White" <address@hidden>
>> >> >Organization: UCAR/Unidata
>> >> >Keywords: 200011101744.eAAHiaD07317
>> >> 
>> >> >> For the GUIs to read the time from the file name, you should use a fil
> e n
>> > ame
>> >> >  like:
>> >> >> 
>> >> >> $RAD/NIDS/MTX/VEL1/VEL1_20001023_1525
>> >> >
>> >> >It already is in this type of format
>> >> >It currently says $RAD/MTX/VEL1/VEL1_20001023_1525
>> >> >
>> >> >It works just fine under under older versions of garp.  
>> >> >
>> >> >Does that mean the new version of gempak changed so you
>> >> >have to add an extra directory level, ie NIDS?
>> >> >
>> >> >
>> >> >Looking at the log file in garp and using truss for nmap, it appears
>> >> >it is reading the radar files just fine.  I see it opening the radar
>> >> >file to look for the dates.  It is having problems in getting the
>> >> >correct dates. 
>> >> >
>> >> >
>> >> >
>> >> >> In particular, for NMAP, the directory name (eg VEL1 must match the
>> >> >> first part of the filename, eg VEL1_20001023_1525).
>> >> >> 
>> >> >> Gpmap of course doesn't look at the file name at all.
>> >> >> 
>> >> >> pqact.conf exaples are available at:
>> >> >> http://www.unidata.ucar.edu/packages/gempak/tutorial/pqact/images.tbl
>> >> >> 
>> >> >> 
>> >> >> Steve Chiswell
>> >> >> Unidata User Support
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> 
>> >> >> >From: "Bryan G. White" <address@hidden>
>> >> >> >Organization: UCAR/Unidata
>> >> >> >Keywords: 200010231559.e9NFx3407261
>> >> >> 
>> >> >> >I'm having problems displaying radar products in nmap and garp.
>> >> >> >
>> >> >> >I'm using gempak 5.6, solaris 7 on a sparc machine.
>> >> >> >
>> >> >> >
>> >> >> >GARP:
>> >> >> >
>> >> >> >I copied over the Garp_defaults file from older version of gempak
>> >> >> >to the new 5.6 version.  Everything works just fine except radar.
>> >> >> >Garp dies and I get this error when garp is reading what date/time
>> >> >> >are available:
>> >> >> >
>> >> >> >ch_to_int_time: Invalid year, 33
>> >> >> >
>> >> >> >Line in Garp_defaults file:
>> >> >> >  nidsT  : $(nids)/%(site)/%(product)/*@(YYYYMMDDHHNN)
>> >> >> >
>> >> >> >When I use truss,  It looks like it doesn't open any files, but
>> >> >> >I get this at the end:
>> >> >> >
>> >> >> >time()                                          = 972316519
>> >> >> >    Incurred fault #6, FLTBOUNDS  %pc = 0xFEDC5558
>> >> >> >      siginfo: SIGSEGV SEGV_MAPERR addr=0x353500F8
>> >> >> >    Received signal #11, SIGSEGV [default]
>> >> >> >      siginfo: SIGSEGV SEGV_MAPERR addr=0x353500F8
>> >> >> >        *** process killed ***
>> >> >> >
>> >> >> >
>> >> >> >NMAP:
>> >> >> >
>> >> >> >Doesn't report any times are available.
>> >> >> >using truss, it does show nmap is opening up all the radar files
>> >> >> >in the directory.
>> >> >> >
>> >> >> >Line in datatype.tbl:
>> >> >> >
>> >> >> >RAD          $RAD                      *YYYYMMDDHHNN             CAT_
> IMG
>> >   S
>> >> > CAT
>> >> >> > _NIL
>> >> >> >
>> >> >> >
>> >> >> >------
>> >> >> >
>> >> >> >gpmap works just fine with radar files.
>> >> >> >
>> >> >> >Here is an example of what a radar file is named:
>> >> >> >MTXVEL1200010231525   
>> >> >> >
>> >> >> >
>> >> >> >So what stupid little thing am I messing up?
>> >> >> >
>> >> >> >
>> >> >> >Bryan        
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> 
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> Unidata User Support                                    UCAR Unidata P
> rog
>> > ram
>> >> >> (303)497-8644                                                  P.O. Bo
> x 3
>> > 000
>> >> >> address@hidden                                   Boulder, CO
>  80
>> > 307
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> Unidata WWW Service                        http://www.unidata.ucar.edu
> /  
>> >    
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> 
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8644                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service                        http://www.unidata.ucar.edu/  
>    
>> >> *************************************************************************
> ***
>> >> 
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>