20010223: 20010216: 20010215: Gridded RCM file

Glenn,

This looks OK to me. You probably have to remove all the old files out of
the $MODEL directory so that nmap doesn't try to open up those when trying
to create the list of available times. If you did do that, then let me know.

Steve Chiswell
Unidata User Support




>From: "Glenn Rutledge" <address@hidden>
>Organization: NCDC
>Keywords: 200102231841.f1NIfeL07282

>This is a multi-part message in MIME format.
>--------------141472A013BED7B9881C4A6C
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Steve,
>Believe it or not, nmap still crashes when using dcgrib2 for the gridded RCM's
> .
>Here's my pqact entry:
>
>WMO ^NOAAPORT\.NWSTG\.GRID\.HAXA00.KWBC\..*
> PIPE /npfos/noaaport/nawips/bin/sol/dcgrib2 -d
>/npraid/noaaport/nawips/logs/%Y%m%d_dcgrib.log
>  -e GEMTBL=/npfos/noaaport/nawips/gempak/tables/grid/
>  /npfos/noaaport/nawipsdata/hds/YYYYMMDD_radar.gem
>
>and attached is the .gem file for your inspection.  I don't see any error msg'
> s
>either.    Thanks much.  Glenn
>
>
>Unidata Support wrote:
>
>> Glenn,
>>
>> Go ahead and change from using dcgrib to dcgrib2. I tested under solaris
>> and that removes the time1:time2 entry in the file. The dcgrib code
>> interprets grib PDS slightly different than dcgrib2. The old code
>> treats the PDS as an accumulation (over an instantaneous time).
>>
>> The DCGRIB2 pqact entry will look like:
>>         PIPE    dcgrib2 -e GEMTBL=...location... YYYYMMDD_radar.gem
>>
>> Basically the same as dcgrib....the only difference in syntax is
>> that dcgrib2 has a differnt syntax for verbose logging (eg -v # instead
>> of just -v in dcgrib) and dcgrib2 always PACKs the output data, so there is 
> never
>> a PACK option on the command line.
>>
>> Anyhow, I think this will finally get you underway.
>>
>> Steve Chiswell
>> Unidata User Support
>>
>> >From: "Glenn Rutledge" <address@hidden>
>> >Organization: NCDC
>> >Keywords: 200102161312.f1GDC8L15105
>>
>> >Thanks Steve,
>> >I'm running dcgrib as per the pqact entry.  I'm decoding on a SUN Ultra60. 
>  Th
>> > anks
>> >much!  I had a feeling is is dying on the number of grids it had to deal wi
> th.
>> >fyi- I'm getting these directly from the NOAAPort broadcast (maybe there is
>  mo
>> > re
>> >grids then your IDD?).  Thanks again.  GLenn
>> >
>> >Unidata Support wrote:
>> >
>> >> Glenn,
>> >>
>> >> I ran gdinfo on your file and find that the times look like:
>> >>  Number of grids in file:    37
>> >>
>> >>  Maximum number of grids in file:   1500
>> >>
>> >>   NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
>> >>     1     010215/0015F000   010215/0015F000        0         NONE RDSP1
>> >>     2     010215/0045F000   010215/0045F000        0         NONE RDSP1
>> >>     3     010215/0115F000   010215/0115F000        0         NONE RDSP1
>> >>     4     010215/0145F000   010215/0145F000        0         NONE RDSP1
>> >>     5     010215/0215F000   010215/0215F000        0         NONE RDSP1
>> >>     6     010215/0245F000   010215/0245F000        0         NONE RDSP1
>> >>
>> >> etc.
>> >>
>> >> On the file that I decoded here with dcgrib2, I have:
>> >>  Number of grids in file:    41
>> >>
>> >>  Maximum number of grids in file:    100
>> >>
>> >>   NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
>> >>     1     010215/0015F000                          0         NONE RDSP1
>> >>     2     010215/0045F000                          0         NONE RDSP1
>> >>     3     010215/0115F000                          0         NONE RDSP1
>> >>     4     010215/0145F000                          0         NONE RDSP1
>> >>     5     010215/0215F000                          0         NONE RDSP1
>> >>     6     010215/0245F000                          0         NONE RDSP1
>> >>     7     010215/0315F000                          0         NONE RDSP1
>> >> etc.
>> >>
>> >> So, it appers that NMAP may be choking on the way the time1:time2
>> >> are in your file. Are you using dcgrib2? What is the platform
>> >> you are decoding on so that I can double check the results.
>> >>
>> >> Thanks,
>> >>
>> >> Steve Chiswell
>> >> *************************************************************************
> ***
>> >> 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/     
>> ****************************************************************************
>