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

20050209: Gempak - WIND= handling in gdplot2



Ron,

The calculations for the vectors will be in MKS units, so the 
specification of "m" or "k" really is only a multiplier for the output,
and is generally only useful in those programs where the vectors are
actually in those units and this implies that SCALE=0, rather than something 
like GVECT = grad(tmpk) where "n" is appropriate and scaling is 
generally needed.

So, yes, in GDPLOT2, if you want barbs for m/s, then type=b
gdpfun=wnd, but for knots, you would use GDPFUN=kntv(wnd).
This is confusing because it is overloading the meaning of
WIND as used in the program.

In the phelp of gdplot2, it does say:

     Winds will be displayed in m/s, unless the KNTV operator has been
     specified in GDPFUN, in which case the winds will be displayed
     in knots.

In otherwords, there is no implicit accounting for units as you state.

Steve Chiswell
Unidata User Support


>From: "Ron McTaggart-Cowan" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200502091640.j19Ged4I021344

>Institution: SUNY Albany
>Package Version: GEMPAK5.7.4
>Operating System: Redhad Fedora Core 1
>Hardware Information: i686 athlon i386 GNU/Linux
>Inquiry: Hi - a quick question about the handling of the WIND=... entry for gd
> plot2.  The WIND docs are specific about the first entry of the string being 
> WIND=[arrow/barb][ms/kts][colour]/....  so that it may look something like WI
> ND=BK1/... for barbs in knots with colour 1.
>
>However, the gdpwnd subroutine in the gdplot2 library explicitly contradicts t
> he WIND docs, saying simply that, 'The first part contains the wind color num
> ber. '.  Indeed, gdpwnd parses the colour out of the first component of the s
> tring and returns its value while ignoring the barb/arrow and ms/knots specif
> ications.  The barb/arrow neglect I understand because it should be set in TY
> PE= .  However, I can't see that the wind units are accounted for elsewhere.
>
>gdplot used to use in_wind to parse the first string component and returned al
> l three values for handling by the main program along with a check that the u
> ser wasn't converting to kts twice.  Does the move away from in_wind mean tha
> t it's up to the user to specify kntv() in gdpfun?
>
>Thanks,
>ron
>
>
>
--
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.