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

[GEMPAK #ZIZ-192685]: Re: 20060123: bugs in gdprof and gdpoint

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [GEMPAK #ZIZ-192685]: Re: 20060123: bugs in gdprof and gdpoint
  • Date: Fri, 10 Mar 2006 14:02:17 -0700
>The second output comes from the
>WIND = BM1
>and is the north-relative component of the total wind -- which more
>people want to know. It is UN(WND), not UREL, and the V is VN(WND)
>not VREL. Setting gfunc = un(wnd) confirms this. And,
>gfunc = ur(vecr(urel,vrel))
>does give back the real, grid-relative east-west component of the
>wind.
>
>So, everything is working as it should, but maybe the winds in the
>second output in gdprof should be relabelled UN and VN or UN(WND)
>VN(WND).


David,

Yes, I agree that is confusing. The GVECT parameter does have the /G option
as shown in the "phelp gdprof" for flagging the output as grid relative
instead of the north relative by default, but the DG_VECT routine
doesn't change the name of the text strings that composed the original.

The GVECT=vecr(urel,vrel) vs GVECT=vecn(un(wnd),vn(wnd)) formulations might be 
less
ambiguous when reading later. Seems that the U component and V component labels
could take that /G flag into account.

Steve Chiswell
Unidata User Support

Ticket Details
===================
Ticket ID: ZIZ-192685
Department: Support GEMPAK
Priority: Urgent
Status: Closed