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

Re: 20020711: DSS090-Reanalysis/nmap nfg

Hello, Steve:
   Well, "never mind." I am unsure of what took place to make this so, but using
fields from a different date, Ruth made a gempak file which nmap can use in
loops. So we have a single
gempak file with lots of levels and variables from the DSS090 Reanalysis set,
covering an
84 hour period, with analyses available every 6 hours. Depending upon "how she
did this" we
may be All Set. If we can't figure out what made it work we may be back with a
Good and Bad
file to see if you have suggestions. (When we have a full understanding of this
I'd appreciate your
guidance on whether it would be worthwhile to prepare a writeup of some kind for
the gempak user archive - we are using scripts which use wgrib and of course
dcgrib. Would such a thing go
into the Contrib directory? I know that most gempak users don't have access to
the SCD/DSS archives directly, so there may be very little interest. Well, I
don't recall what was there about use of the Ranalysis CD-ROM data; we could
certainly write that up....)
    I'll want to test the limits by including additional variables, including
both isobaric and isentropic analyses, stuff like that. If this introduces (or
re-creates) problems, I could imagine keeping separate files with subsets of the
data as a workable compromise. Also, I'm going to be editing the mod_res.tbl and
other parameter files, primarily to tailor the nmap menus to speed up my work.
  Thanks for your help with this.                John


From address@hidden Fri Jul 12 09:36:34 2002
Received: from gsosun1.gso.uri.edu (gsosun1.gso.uri.edu [131.128.101.1])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id g6CFaXa06149;
        Fri, 12 Jul 2002 09:36:33 -0600 (MDT)
Keywords: 200207121536.g6CFaXa06149
Received: from boreas.gso.uri.edu (boreas.gso.uri.edu [131.128.102.63])
        by gsosun1.gso.uri.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA19301;
        Fri, 12 Jul 2002 11:36:32 -0400 (EDT)
Received: from boreas.gso.uri.edu (localhost [127.0.0.1])
        by boreas.gso.uri.edu (8.9.3+Sun/8.9.1) with ESMTP id LAA03924;
        Fri, 12 Jul 2002 11:36:05 -0400 (EDT)
Sender: address@hidden
Message-ID: <address@hidden>
Date: Fri, 12 Jul 2002 11:36:01 -0400
From: John Merrill <address@hidden>
Reply-To: address@hidden
Organization: University of Rhode Island
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Unidata Support <address@hidden>
CC: address@hidden, address@hidden,
   Ruth Platner <address@hidden>
Subject: Re: 20020711: DSS090-Reanalysis/nmap nfg
References: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello, Steve:
     We have successfuly concatenated multiple analysis times in a file, from 
the

Reanalysis CD-ROM, but haven't been able to do so form the DSS090 set. I've run
nmap on the CD-ROM-generated file and can loop multiple times. When I try this
with
the file generated from the DSS data I see Errors and corresponding blank frames
in the loop.
   Here are listings from gdinfo for two files, shortened by asking only for the
height at 500 -
similar results abound at other levels and for other variables:

First, from the CD
GEMPAK-GDINFO>run

 GRID FILE: /arifi/rlp/gempak/nogaps/rean_2001040112.gem

 GRID NAVIGATION:
     PROJECTION:          CED
     GRID SIZE:          144  73
     LL CORNER:             -90.00      0.00
     UR CORNER:              90.00     -2.50

 GRID ANALYSIS BLOCK:
      UNKNOWN ANALYSIS TYPE

 Number of grids in file:   152

 Maximum number of grids in file:   1500

  NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
    8     010401/1200F000                        500         PRES HGHT
   27     010402/0000F000                        500         PRES HGHT
   46     010402/1200F000                        500         PRES HGHT
   65     010403/0000F000                        500         PRES HGHT
   84     010403/1200F000                        500         PRES HGHT
  103     010404/0000F000                        500         PRES HGHT
  122     010404/1200F000                        500         PRES HGHT
  141     010405/0000F000                        500         PRES HGHT
 Parameters requested: GDFILE,LSTALL,OUTPUT,GDATTIM,GLEVEL,GVCORD,GFUNC.

Second from the DSS 090 set:

GEMPAK-GDINFO>run

 GRID FILE: /arifi/rlp/gempak/nogaps/rean_2001040100.gem

 GRID NAVIGATION:
     PROJECTION:          CED
     GRID SIZE:          144  73
     LL CORNER:             -90.00      0.00
     UR CORNER:              90.00     -2.50

 GRID ANALYSIS BLOCK:
      UNKNOWN ANALYSIS TYPE

 Number of grids in file:   720

 Maximum number of grids in file:   1500

  NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
   26     010401/0000F000                        500         PRES HGHT
  106     010401/0600F000                        500         PRES HGHT
  186     010401/1200F000                        500         PRES HGHT
  266     010401/1800F000                        500         PRES HGHT
  346     010402/0000F000                        500         PRES HGHT
  426     010402/0600F000                        500         PRES HGHT
  506     010402/1200F000                        500         PRES HGHT
  586     010402/1800F000                        500         PRES HGHT
  666     010403/0000F000                        500         PRES HGHT
 Parameters requested: GDFILE,LSTALL,OUTPUT,GDATTIM,GLEVEL,GVCORD,GFUNC.

We're not close to the current or absolute maximum number of grids. With the CD
set gempak
(and nmap) seem to tolerate the different times (all F0000) just fine; that is,
pleasingly, it doesn't seem to matter whether I am marching through a set of
forecasts or of analyses.

So, to reiterate (at the risk of boring you), gdinfo can "see" the grids, in 
both
cases. But when
I try to use them, either in nmap or in gdcntr, for example, some of the grids
from the DSS090
set are unreachable, and either nothing shows up (nmap, Error!) or an error
message or incorrect time is plotted (gdcntr).

I'm looking at some additional files to explore this further, and pending what I
find I may
put a couple of files in your ftp area.                                   John


- - - - - - - - - - - - - - - - - - - - - -
Unidata Support wrote:

> John,
>
> NMAP uses the file name templates in $GEMTBL/config/datatype.tbl
> to identify which files would have given times in them. Generally,
> the model templates are files such as YYYYMMDDHH. If you are
> combining multiple analysis times in a file, then that could
> be a problem with NMAP (and gdcntr if you are using the template
> as the GDFILE instead of the actual file name).
>
> Other than that, gdcntr shouldn't care if there are multiple
> analysis times in a file.
>
> The maximum number of grids in a file is currently 30,000
> (the maximum number of headers).
>
> The maximum number of grid times in a file is in GEMPRM.PRM:
>         PARAMETER       ( LLMXGT =  1000   )
> C!                                              Max # grid times
>
> If you have 8 analysis times, you won't have a problem with the 1000
> time limit (unless you have a couple of hundered forecast times
> per analysis).
>
> If you want to send me a file, you can ftp into the ~gbuddy/incoming
> directory on ftp.unidata.ucar.edu using the old XXXXXX
> password.
>
> Steve Chiswell
> Unidata User Support
>