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

20020716: nmap/reanalysis followup



John,

What version of GEMPAK are you running? 5.6.f?
Just wondering if there is a template problem that
allows NMAP to find files in the same directory that don't match the
expected template. What are the file names, and the respective templates?

As for vertical coordinates....sure, any number can be in a file.
For instance, the MAXW level, EATM, NONE, PRES, THTA, HYBL, HGHT, HAGL,
PDLY etc.

When doing calculations that involve multiple coordinate, just use the
"%" inline (eg @, ^ and %) modifier if necessary.

Steve Chiswell
Unidata User Support



>From: John Merrill <address@hidden>
>Organization: University of Rhode Island
>Keywords: 200207161613.g6GGDEH24889

>
>--------------9A80CC2D068B9326682BB273
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Hello, Steve:
>   Based in part upon your help, we have figured out and corrected the
>problems we were
>having in nmap with Reanalysis files generated from Mass Store data
>sets.
>   We had a problem working with gempak files from DSS data sets when
>they were adjacent
>to gempak files generated from the NCAR CD-ROM subset of the Reanalysis
>set. The CD
>fields were at a subset of the isobaric levels, and were at reduced
>frequency, twice per day
>vs. four times per day. The mere presence of these subset files in the
>directory caused nmap
>to get bollixed up. For a "data source" with none of the subset files
>present, nmap would "see" the entire set of analysis times; when one or
>more subset files were present it was as if the 0600
>and 1800 data were unavailble. A distinct, but related, problem arose
>because of a GDATTIM
>specification in some, but not all, of the Model Resource "Restore"
>files. Those Restore files
>with GDATTIM=fall, when used, showed data only at the _last_ time in the
>file; using
>a Restore file without the GDATTIM specification allowed nmap to "see"
>all the times.
>   So we are progressing nicely. I have two questions, one of which is
>rhetorical. First, the
>practical question. Can we mix vertical coordinates in a gempak file and
>not bollix things up? I assume we can. So we have lots of isobaric
>fields in a file, and want to re-make the file and
>include some vcord=thta fields. Ruth was worried that when THTA=300
>gempak might be
>confused between the data, e.g., UGRD and VGRD, which are available both
>on that level and
>on the PRES=300 grid. I figure gempak knows the distinction, because how
>else could we have
>both isobaric and surface data in a file, as I know we do in some cases.
>
>   The rhetorical question is one whose answer I don't really care to
>know, and I mention it
>only for the sake of completeness. Why would nmap be bollixed up by the
>additional files in
>a directory if it does not need to look in those files to find the data
>it needs? Seems confusing to
>me, but I suppose I have as large a collection of such confusing things
>as anyone...
>  Again, thanks for your help with getting access to these Reanalysis
>files.   John
>
>--
>
>John Merrill                                     Telephone:  401-874-6715
>Graduate School of Oceanography, URI             Fax:        401-874-6898
>
>
>
>--------------9A80CC2D068B9326682BB273
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
><html>
>Hello, Steve:
><br>&nbsp;&nbsp; Based in part upon your help, we have figured out and
>corrected the problems we were
><br>having in nmap with Reanalysis files generated from Mass Store data
>sets.
><br>&nbsp;&nbsp; We had a problem working with gempak files from DSS data
>sets when they were adjacent
><br>to gempak files generated from the NCAR CD-ROM subset of the Reanalysis
>set. The CD
><br>fields were at a subset of the isobaric levels, and were at reduced
>frequency, twice per day
><br>vs. four times per day. The mere presence of these subset files in
>the directory caused nmap
><br>to get bollixed up. For a "data source" with none of the subset files
>present, nmap would "see" the entire set of analysis times; when one or
>more subset files were present it was as if the 0600
><br>and 1800 data were unavailble. A distinct, but related, problem arose
>because of a GDATTIM
><br>specification in some, but not all, of the Model Resource "Restore"
>files. Those Restore files
><br>with GDATTIM=fall, when used, showed data only at the _last_ time in
>the file; using
><br>a Restore file without the GDATTIM specification allowed nmap to "see"
>all the times.
><br>&nbsp;&nbsp; So we are progressing nicely. I have two questions, one
>of which is rhetorical. First, the
><br>practical question. Can we mix vertical coordinates in a gempak file
>and not bollix things up? I assume we can. So we have lots of isobaric
>fields in a file, and want to re-make the file and
><br>include some vcord=thta fields. Ruth was worried that when THTA=300
>gempak might be
><br>confused between the data, e.g., UGRD and VGRD, which are available
>both on that level and
><br>on the PRES=300 grid. I figure gempak knows the distinction, because
>how else could we have
><br>both isobaric and surface data in a file, as I know we do in some cases.
><br>&nbsp;&nbsp; The rhetorical question is one whose answer I don't really
>care to know, and I mention it
><br>only for the sake of completeness. Why would nmap be bollixed up by
>the additional files in
><br>a directory if it does not need to look in those files to find the
>data it needs? Seems confusing to
><br>me, but I suppose I have as large a collection of such confusing things
>as anyone...
><br>&nbsp; Again, thanks for your help with getting access to these Reanalysis
>files.&nbsp;&nbsp; John
><pre>--&nbsp;
>
>John Merrill&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel
> ephone:&nbsp; 401-874-6715
>Graduate School of Oceanography, URI&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>  401-874-6898</pre>
>&nbsp;</html>
>
>--------------9A80CC2D068B9326682BB273--
>