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

20051101: gempak issues version 5.7.4

Frank,

When time, coordinate, or level is not specified in the GFUNC line,
then it will inherit them from the GDATTIM, GVCORD and GLEV values.
The most likely problem is with your GDATTIM, which isn't shown,
but is a common problem, in that if not fully specified, will
use defaults referenced from the first file. 

For example, if GDATTIM=f000, then that will assume to mean the f000
time found in the first file. If the second file has different forecast
times, then that results in one instance of the problem you have.

Since I suggest using GDPLOT2 instead of GDPLOT, as GDPLOT2 has a superset
of plotting capabilities of GDPLOT, I'll show an example using that program:

 GDFILE   = $MODEL/eta/2005110112_eta212.gem + $MODEL/gfs/2005110118_eta212.gem
 GDATTIM  = f000
 GLEVEL   = 500
 GVCORD   = pres

If GDPFUN=hght, the plot works. If GDPFUN=hght+2, the plot doesn't work, and
the error message is that HGHT ^051101/1200F000 @500 %PRES cannot be found.

Instead, to plot the f000 hght field from the 18Z run in the second file:

GDPFUN=hght^1800f000+2

or

GDATTIM=1800f000
GDPFUN=hght+2

The reason illustrated is that f000 is ambiguous, and will use the most recent
f000 time found in the first file, which is the 12Z f000 rather than 18Z f000.
When the time is specified as 1800f000 in either the GDATTIM, or the GDPFUN
variable, that ambiguity is resolved. The error message plots the file time
from the first file, because that is the source of the data that was used to 
fill in the missing parts of the GDATTIM. 

From your file names, I can't tell if all times in the files would exist etc,
or what your GDATTIM, GLEVEL, GVCORD are, or what should be expected to be in 
each file,
but the most likely thing to look for is the ambiguity in one of these 
variables.

Note that I just tested this using the current GEMPAK release (rather than 
5.7.4).
You may find the GDPLOT2 error messages slightly more informative, and since 
that
combines the GDPLOT capability with gdstream and gdmap as well as gdcntr and 
gdwind,
I suggest developing new plots with that, and just using gdplot for legacy 
scripts.
Eventually the old gdplot will go away as it takes NCEP time to keep porting the
updates to that program as well.

Steve Chiswell
Unidata User Support


>From: Frank Colby <address@hidden>
>Organization: UMass Lowell
>Keywords: 200511011542.jA1FgR7s013926

>This is a multi-part message in MIME format.
>--------------010100020205020707020904
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Dear Unidata Support,
>
>I'm trying to open multiple gempak gridded files in gdplot, but am 
>unable to manipulate them.  I tried following the help files, using the 
>format suggested, namely,
>
>GDFILE = $HDS/2005020209_eta315.gem + $HDS/2005020209_eta316.gem
> and get no file errors with this, but when I try to plot usnig 
>something like
>
>GFUNC = advg(tmpk+2, wnd)   I do get an error that one of the fields 
>isn't found.
>
>If I try:
>GFUNC = tmpk  I get a plot from the first file
>GFUNC = tmpk+1  produces the same plot as without the +1
>GFUNC = tmpk+2 produces an error, "unable to find the field at 
>level....., but it references the FIRST file, not the second file.  This 
>is odd in two ways -- first why is the software not looking at the 
>second file, and second, why is the field now not there, when it plots 
>it without the +2?
>
>
>
>Obviously I'm doing something wrong -- any ideas what that might be?
>
>Thanks,
>
>Frank Colby
>UMass Lowell
>
>
>--------------010100020205020707020904
>Content-Type: text/x-vcard; charset=utf-8;
> name="Frank_Colby.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
> filename="Frank_Colby.vcf"
>
>begin:vcard
>fn:Frank Colby
>n:Colby;Frank
>org:University of Massachusetts Lowell;Environmental, Earth & Atmospheric Scie
> nces
>email;internet:address@hidden
>title:Professor of Meteorology
>tel;work:(978) 934-3906
>version:2.1
>end:vcard
>
>
>--------------010100020205020707020904--
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.