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

20011206: 20011203: 20011130: 20011130: Computing the standard deviatio n

Andy,

No. STAN C should not be .1849. Your assumption that operations are
commutative is incorrect. The square of a number is not linear.
Therefore, you cannot interpolate B to and point and then square it
and have it equal to the field of B^2 interpolated to a point.
The STAN value of .29 does appear to be the correct interpolated value
of the B^2 field to SAC. You can plot out the 4 surrounding data points of SAC 
and
do the bi-linear interpolation yourself to prove this.

To prove that the operations are non-commutative, look simply at 2 points:


     Pt1             Pt2
       +------*------+
      

Now, say you want to interpolate B and C to the * in the middle of the 2 points.

Given the values B and C=B^2:

    Pt1      Pt2
B   .77     -.01
C   .593     .0001

An interpolation of B to * gives: .39
An interpolation if C to * gives: .2965

If you then square the value of B interpolated to the point, you get: .39^2 = 
.1521


By calculating C first, and interpolating the field to the station location, 
you have a 
field that reflects the non-linearity of the gradient in the square of the 
quantities.

I have found nothing in the information you provided to point to any problems 
with
the package.

Steve Chiswell
Unidata User Support




>From: "Siffert, Andy" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200112061615.fB6GExN29055

>This message is in MIME format. Since your mail reader does not understand
>this format, some or all of this message may not be legible.
>
>------_=_NextPart_000_01C17E71.2620E9E0
>Content-Type: text/plain;
>       charset="iso-8859-1"
>
>
>Steve,
>Sorry to keep bothering you with this problem,
>I tried the changes but things were pretty much the same as I had. The
>problem still exists and I see you had the same problem. STAN "C" should be
>.1849
>
>    STN    YYMMDD/HHMM      STAN     SLAT     SLON
>    SAC    011203/0000      0.29    38.52  -121.50
>
>So, I still think it is how the gdgdiag is storing "b" into the
>"2001120300_ensemble.gem" file.
>I did not see a problem with the Lat,Lon, but I have attached the
>"2meter_temp.sfc" as requested
>Also attached is the script I'm using "standard.tcsh"
>You should be able to use in it, in any working directory where the .gem
>file is. I believe you just need to source your location of Gemenviron. I
>just do not understand what I'm doing wrong. Everything seems right and it's
>such a simple calculation "b^2"
>
>Sorry, but Thanks,
>Andy 
>
>
>-----Original Message-----
>From: Unidata Support [mailto:address@hidden]
>Sent: Wednesday, December 05, 2001 2:04 PM
>To: Siffert, Andy
>Cc: 'Unidata Support'
>Subject: 20011203: 20011130: 20011130: Computing the standard deviation 
>
>
>
>
>Andy,
>
>I took your grid file and verified that I can display the "C" quantity for
>f000.
>
>I then created a surface file with:
> SFOUTF   = 2meter_temp.sfc
> SFPRMF   = TMC1;AVRG;STAN;MINS;PLUS
> STNFIL   = sfmetar_sa.tbl
> SHIPFL   = n
> TIMSTN   = 24/100
> SFFSRC   = text
> GEMPAK-SFCFIL>
>
>In the above, sfmetar_sa.tbl is a surface file with SAC (Sacremento, CA) in
>it.
>As I mentioned previously, your use of TIMSTN was not correct.
>
>I then used gdgsfc to write the grid "C" to the surface file and
>call it "STAN".
>
> GDFILE   = 2001120300_ensemble.gem
> GDATTIM  = f000
> GVCORD   = hght
> GLEVEL   = 2
> GFUNC    = c
> SCALE    = 999
> SFFILE   = 2meter_temp.sfc
> SFPARM   = dset
> GEMPAK-GDGSFC>sfparm = stan
> GEMPAK-GDGSFC>r
>
> Grid file: 2001120300_ensemble.gem
>
> GRID IDENTIFIER: 
>    TIME1             TIME2         LEVL1 LEVL2   VCORD PARM
>011203/0000F000                         2          HGHT C           
>
>                                                   SCALE:  0
>
> File:              2METER_TEMP.SFC
>
> Time:              011203/0000         
>
> Parameter:         STAN
>
>Enter <cr> to accept parameters or type EXIT:
> Parameters requested: GDFILE,GDATTIM,GVCORD,GLEVEL,GFUNC,SCALE,SFFILE,
> SFPARM.
> GEMPAK-GDGSFC>
>
>
>
>I can now list out the value of STAN (which is b^2) with SFLIST:
>
> SFFILE   = 2meter_temp.sfc
> AREA     = @sac
> DATTIM   = all
> SFPARM   = stan;slat;slon
> OUTPUT   = t
> IDNTYP   = STID
> GEMPAK-SFLIST>r
> PARM = STAN;SLAT;SLON
>
>
>    STN    YYMMDD/HHMM      STAN     SLAT     SLON
>    SAC    011203/0000      0.29    38.52  -121.50
> 
> 
> Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP.
> GEMPAK-SFLIST>
>
>
>
>This appears to be what you said you could not get. I included the
>SLAT and SLON output in sflist as well since it could be that if your
>station table you are using has a problem with the location of SAC,
>then you could get -9999 as STAN if the SLAT and SLON were not known.
>If that is the case we'd have to have a look at your 
>/usr/local/nawips/gempak/tables/stns/2m_temp.tbl file.
>
>So at this point, I need you to verify that you are doing as I am above
>and you still see -9999 for the STAN value of SAC.
>
>
>Steve Chiswell
>Unidata User Support
>
>
>
>
>
>
>>From: "Siffert, Andy" <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200112031432.fB3EWoN04424
>
>>Good Morning Steve, 
>>Is there a ftp site I can ftp you the .gem file it is still to big to send
>>through e-mail. 
>>What I did is did a 
>>gddlet
>>I deleted all the other parameters for all forecast hours except for F000
>>and F012. 
>>However, this did not change the size of the .gem file, it just removed the
>>unwanted grids. Is there anyway to change the size of a gempak file. 
>>
>>Thanks,
>>Andy
>>
>>
>>
>>
>>-----Original Message-----
>>From: Unidata Support [mailto:address@hidden]
>>Sent: Friday, November 30, 2001 2:46 PM
>>To: Siffert, Andy
>>Cc: 'Unidata Support'
>>Subject: 20011130: 20011130: Computing the standard deviation 
>>
>>
>>
>>Andy,
>>
>>Ok. Still can't see any problem (other than TIMSTN which exceeds the
>default
>>number of times allow in a GEMPAK file). I used TIMSTN=24/100 for
>>24 times, 100 additional stations.
>>
>>Rereading your message below, you say you use gdgsfc to write the gddiag
>>values
>>to a surface file. Then output to a .txt file.
>>
>>Have you looked at the values in the surface file with sflist?
>>what are you using to output the data to your .txt file?
>>
>>I guess I should see your gdgsfc commands, the SAC output from sflist
>>as well.
>>
>>Steve Chiswell
>>Unidata User SUpport
>>
>>
>>
>>>From: "Siffert, Andy" <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200111301947.fAUJlCN29728
>>
>>>
>>>Steve,
>>>
>>>This is the surface file I created. 
>>>
>>>
>>>TMC1 = TMPKC001
>>>AVRG=  Average of all members
>>>STAN= Will equal Standard deviation  once I can figure out b^2
>>>MINS= Average - one Standard Deviation
>>>PLUS= Average + one Standard Deviation 
>>>
>>>
>>>
>>>
>>>sfcfil<<EOF
>>>SFOUTF=/home/met-user/andy/2meter_temp.sfc
>>>SFPRMF=TMC1;AVRG;STAN;MINS;PLUS
>>>STNFIL=/usr/local/nawips/gempak/tables/stns/2m_temp.tbl
>>>SHIPFL=NO
>>>TIMSTN=1000 
>>>SFFSRC=text
>>>
>>>run
>>>   
>>>EOF
>>>
>>>Not sure if I understand this part 2)
>>>2) specify a parameter list and optionally the data range and resolution
>>>   of the data.
>>>
>>>
>>>Thanks,
>>>Andy 
>>>
>>>-----Original Message-----
>>>From: Unidata Support [mailto:address@hidden]
>>>Sent: Friday, November 30, 2001 1:32 PM
>>>To: Siffert, Andy
>>>Cc: 'Unidata Support'
>>>Subject: 20011130: 20011130: Computing the standard deviation 
>>>
>>>
>>>
>>>Andy,
>>>
>>>this confirms that it is not a problem related to your
>>>calculation of C in gddiag. previously, you had said you saw values
>>>of -9999 for C, but we now can assume that it is when you interpolate the
>>>grid to the surface file using gdgsfc.
>>>
>>>When you use gdgsfc, the surface file must already exist. Presumably
>>>you have created the surface file using sfcfil. The resolution of the
>>>data to be stored in the surface file is specified with the SFPRMF
>>>parameter.
>>>
>>>So, we need to see what you have done for SFPRMF in sfcfil.
>>>Typically, you can either:
>>>1) specify a packing file
>>>2) specify a parameter list and optionally the data range and resolution
>>>   of the data.
>>>
>>>Can you provide information on what you have used for SFPRMF?
>>>
>>>Steve Chiswell
>>>Unidata User Support
>>>
>>>
>>>
>>>
>>>
>>>>From: "Siffert, Andy" <address@hidden>
>>>>Organization: UCAR/Unidata
>>>>Keywords: 200111301919.fAUJJEN28104
>>>
>>>>
>>>>Steve,
>>>>I'm some what new to Gempak,
>>>>I'm not sure what I'm suppose to be looking for when I use gdinfo or
>>gdcntr
>>>>
>>>>When using gdinfo and gdcntr
>>>>I specify "b" or "c" 
>>>>and it shows that they are there.
>>>>Is that what you wanted me to see??
>>>>
>>>>I do agree with you that is it s truncating problem. 
>>>>When you get a chance it would be great if you could return this e-mail
>>and
>>>>I could give you a call to get a better understanding of where the
>problem
>>>>might be.
>>>>Thanks,
>>>>Andy 
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Unidata Support [mailto:address@hidden]
>>>>Sent: Friday, November 30, 2001 10:09 AM
>>>>To: Siffert, Andy
>>>>Cc: 'Unidata Support'
>>>>Subject: 20011130: 20011129: Computing the standard deviation 
>>>>
>>>>
>>>>
>>>>
>>>>Andy,
>>>>
>>>>start by forgetting about gdgsfc to start.
>>>>
>>>>After you create "b" which you know works, you should be able to use
>>>>gdlist or gdcntr etc to view it.
>>>>
>>>>Now, if you create "c", you should still be able to view it. Verify that
>>>>first- before doing anything with gdgsfc,
>>>>
>>>>What I see in your previous message is that your terms are small. And
>when
>>>>you 
>>>>square them, they of course get smaller. The SFLIST output will be
>>>>truncated to 2 decimal places which does create a display problem, unless
>>>>you
>>>>scale the values with SFPARM=sstdv*100 for example.
>>>>
>>>>If you are using gdgsfc to write the output to the surface file, then the
>>>>packing information for the surface file must correspond to the
>>>>resolution of the data (see $GEMTBL/pack for examples). 
>>>>
>>>>Anyhow, let me know first if you see C in the grid file before the gdgsfc
>>>>interpolation to a surface file. If that is the case, then we can focus
>on
>>>>what
>>>>you need to use with gdgsfc. As I mentioned yesterday, I didn't see
>>>>any problem here with gddiag.
>>>>
>>>>Steve Chiswell
>>>>Unidata User Support
>>>>
>>>>
>>>>
>>>>
>>>>>From: "Siffert, Andy" <address@hidden>
>>>>>Organization: UCAR/Unidata
>>>>>Keywords: 200111301327.fAUDRTN10376
>>>>
>>>>>Steve good morning.
>>>>>We are running a newer version of Red Hat Linux and using GEMPACK
>5.6.c.1
>>
>>>>>(I think c.1) 
>>>>>
>>>>> MRF ensemble grid I'm using. 
>>>>>GRID NAVIGATION: 
>>>>>     PROJECTION:          CED                 
>>>>>     GRID SIZE:          144  73
>>>>>     LL CORNER:             -90.00      0.00
>>>>>     UR CORNER:              90.00     -2.50
>>>>>
>>>>>First using a series of gddiag commands I create an average using all
>the
>>>>>members.  
>>>>>The average is then stored in the same .gem as the 10 members. 
>>>>>Next I individually take the members and compute the variance, from the
>>>>>variance you take the sqrt to obtain the standard deviation. 
>>>>>
>>>>>The problem is in the calculation of the variance.
>>>>>as noted in my previous e-mail.
>>>>>
>>>>>As far as viewing the output. Once, all the calculation for all the
>>>members
>>>>>and all forecast hours, are computed in gddiag. I then use gdgsfc to
>>write
>>>>>the selected surface that were written to file in the gddiag commands.
>>>Then
>>>>>using gdgsfc I write everything to a .txt file. 
>>>>>
>>>>>P.S. I know that GEMPAK knows what b is because if I
>>>>>for example use the 11/30 00z, TMPKC001 member from SAC 
>>>>>The:
>>>>>AVG (of all the members) = 43.76
>>>>>TMPKC001 = 43.46
>>>>>AVG - TMPKC001 = .30 (b)
>>>>>mul(b,b)= .25
>>>>>exp(b,2)= -9999 (however for some other STN ID's I do not get -9999).
>>>>>exp(.30,2)= .09
>>>>>mul(.30,.30)= .09 which is what I want but since .30 is just one example
>>>of
>>>>>many members I need to use (b).
>>>>>
>>>>>Hope this additional information helps.
>>>>>Thanks for your help.
>>>>>Andy
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Unidata Support [mailto:address@hidden]
>>>>>Sent: Thursday, November 29, 2001 3:33 PM
>>>>>To: Siffert, Andy
>>>>>Cc: address@hidden
>>>>>Subject: 20011129: Computing the standard deviation 
>>>>>
>>>>>
>>>>>
>>>>>Andy,
>>>>>
>>>>>I cannot duplicate your problem here using GEMPAK 5.6.E.1 on my SGI
>>>>>with the 00Z ensemble grids on the 1x1 degree output today.
>>>>>What platform combination are you using?.
>>>>>
>>>>>Where is your "example of output" coming from? GDLIST? GDPLOT2?
>>>>>
>>>>>Steve Chiswell
>>>>>
>>>>>
>>>>>
>>>>>>From: "Siffert, Andy" <address@hidden>
>>>>>>Organization: UCAR/Unidata
>>>>>>Keywords: 200111291537.fATFbvN06225
>>>>>
>>>>>>
>>>>>>Steve
>>>>>>I Think?
>>>>>>
>>>>>>I'm not sure how large or small my problem is. However, I hope I made
>my
>>>>>>problem clear below.
>>>>>>What I'm trying to do in gempak is take the square of small number and
>>>>>store
>>>>>>it in a .gem file using GDDIAG. 
>>>>>>
>>>>>>What I'm trying to do is compute the standard deviation in 2 m
>>>temperature
>>>>>>from the MRF ensembles 
>>>>>>
>>>>>>here is the part of interest.
>>>>>>
>>>>>>#converts member to degrees F
>>>>>>gddiag<<EOF
>>>>>>GDFILE   = /home/met-user/andy/$file
>>>>>>GDOUTF   = /home/met-user/andy/$file
>>>>>>GFUNC    = add(mul(sub(TMPKC001,273),1.8),32)))
>>>>>>GDATTIM  = $YY$MM$DD/${cycle}00F$zero$fff
>>>>>>GLEVEL   = 2
>>>>>>GVCORD   = hght
>>>>>>GRDNAM  = a
>>>>>>GPACK    = 
>>>>>>run
>>>>>>
>>>>>>EOF
>>>>>>
>>>>>>#Subtract avg from a member of the ensembles
>>>>>>gddiag<<EOF
>>>>>>GDFILE   = /home/met-user/andy/$file
>>>>>>GDOUTF   = /home/met-user/andy/$file
>>>>>>GFUNC    = sub(avg,a)
>>>>>>GDATTIM  = $YY$MM$DD/${cycle}00F$zero$fff
>>>>>>GLEVEL   = 2
>>>>>>GVCORD   = hght
>>>>>>GRDNAM   = b
>>>>>>GPACK    =
>>>>>>run
>>>>>>
>>>>>>EOF
>>>>>>
>>>>>>gddiag<<EOF
>>>>>>GDFILE   = /home/met-user/andy/$file
>>>>>>GDOUTF   = /home/met-user/andy/$file
>>>>>>GFUNC    = expi(b,2)
>>>>>>GDATTIM  = $YY$MM$DD/${cycle}00F$zero$fff
>>>>>>GLEVEL   = 2
>>>>>>GVCORD   = hght
>>>>>>GRDNAM   = c
>>>>>>GPACK    =
>>>>>>run
>>>>>>
>>>>>>EOF
>>>>>>
>>>>>>This is where the problem is: I want to take the square of b (b^2).
>>>>>>The output is wrong. 
>>>>>>
>>>>>>I have even try doing
>>>>>>    GFUNC = mul (b,b) 
>>>>>>which should be the same as b^2?
>>>>>>If I use 
>>>>>>   GFUNC = EXP(b,2)  
>>>>>>I get -9999 or the wrong answer also.
>>>>>>
>>>>>>Example of output
>>>>>>  Avg -  a  =  b^2  =    c       The output I recive from C in gempak
>>>>>>43.31-42.82 = .49 ^2 = .2401      .27
>>>>>>53.56-53.54 = .02 ^2 = .0004      -9999
>>>>>>
>>>>>>Thanks for your help.
>>>>>>Andy 
>>>>>>
>>>>>>
>>>>>>
>>>>>>****************************************
>>>>>>               Andy Siffert                  
>>>>>>        Aquila Weather Desk           
>>>>>>     Research and Development     
>>>>>>  1100 Walnut Street, Suite 3300  
>>>>>>      Kansas City, MO 64106         
>>>>>>             816-527-1247                 
>>>>>>          Fax: 816-527-4247            
>>>>>>****************************************
>>>>>>
>>>>>
>>>>>************************************************************************
>*
>>*
>>>*
>>>>*
>>>>><
>>>>>Unidata User Support                                    UCAR Unidata
>>>>Program
>>>>><
>>>>>(303)497-8644                                                  P.O. Box
>>>>3000
>>>>><
>>>>>address@hidden                                   Boulder, CO
>>>>80307
>>>>><
>>>>>------------------------------------------------------------------------
>-
>>-
>>>-
>>>>-
>>>>><
>>>>>Unidata WWW Service                        http://www.unidata.ucar.edu/
>>>>><
>>>>>************************************************************************
>*
>>*
>>>*
>>>>*
>>>>><
>>>>>
>>>>
>>>>*************************************************************************
>*
>>*
>>>*
>>>><
>>>>Unidata User Support                                    UCAR Unidata
>>>Program
>>>><
>>>>(303)497-8644                                                  P.O. Box
>>>3000
>>>><
>>>>address@hidden                                   Boulder, CO
>>>80307
>>>><
>>>>-------------------------------------------------------------------------
>-
>>-
>>>-
>>>><
>>>>Unidata WWW Service                        http://www.unidata.ucar.edu/
>>>><
>>>>*************************************************************************
>*
>>*
>>>*
>>>><
>>>>
>>>
>>>**************************************************************************
>*
>>*
>>><
>>>Unidata User Support                                    UCAR Unidata
>>Program
>>><
>>>(303)497-8644                                                  P.O. Box
>>3000
>>><
>>>address@hidden                                   Boulder, CO
>>80307
>>><
>>>--------------------------------------------------------------------------
>-
>>-
>>><
>>>Unidata WWW Service                        http://www.unidata.ucar.edu/
>>><
>>>**************************************************************************
>*
>>*
>>><
>>>
>>
>>***************************************************************************
>*
>><
>>Unidata User Support                                    UCAR Unidata
>Program
>><
>>(303)497-8644                                                  P.O. Box
>3000
>><
>>address@hidden                                   Boulder, CO
>80307
>><
>>---------------------------------------------------------------------------
>-
>><
>>Unidata WWW Service                        http://www.unidata.ucar.edu/
>><
>>***************************************************************************
>*
>><
>>
>
>****************************************************************************
><
>Unidata User Support                                    UCAR Unidata Program
><
>(303)497-8644                                                  P.O. Box 3000
><
>address@hidden                                   Boulder, CO 80307
><
>----------------------------------------------------------------------------
><
>Unidata WWW Service                        http://www.unidata.ucar.edu/
><
>****************************************************************************
><
>
>
>------_=_NextPart_000_01C17E71.2620E9E0
>Content-Type: application/octet-stream;
>       name="standard.tcsh"
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: attachment;
>       filename="standard.tcsh"
>
>#!/bin/tcsh
>#
>#environment stuff
>#
>#This script make a surface text file of 2 meter temperature for a =
>select
>#number of Cities in the US using the NCEP ensembles.
>
>set echo
>
>source /usr/local/nawips/Gemenviron
>
>#cd /home/met-user/andy/tmp/
>
>
># Setting up Date Time Stamp
>
>
># Need to have it pick the newest file that was created. This is done =
>by
>#using the ls -t | head -1 | cut -c1-10
>
>#  set newfile =3D  `ls -t | head -1`
>#  set YY =3D    `ls -t | head -1 | cut -c3-4`
>#  set MM =3D    `ls -t | head -1 | cut -c5-6`
>#  set DD =3D    `ls -t | head -1 | cut -c7-8`
>#  set HH =3D    `ls -t | head -1 | cut -c9-10`
>#  set cycle =3D `ls -t | head -1 | cut -c9-10`
>
>#cp $newfile /home/met-user/andy/
>
>cd=20
>
>cd ./andy/tmp/
>
>set newfile =3D  2001120300_ensemble.gem
>  set YY =3D     01
>  set MM =3D     12
>  set DD =3D     03
>  set HH =3D     00
>  set cycle =3D  00
>
>
>
> set file =3D 2001120300_ensemble.gem
>
>chmod a+w $file
>
>
>rm -f 2meter_temp.sfc
>rm -f ???_temp.sfc
>rm -f temperature.txt
>
>
>sfcfil<<EOF
>SFOUTF=3D2meter_temp.sfc
>SFPRMF=3DTMC1;AVRG;STAN;MINS;PLUS
>STNFIL=3D2m_temp.tbl
>SHIPFL=3Dn
>TIMSTN=3D24/100
>SFFSRC=3Dtext
>
>run
>
>EOF
>
>gpend
>=20
># Create the surface file using GDGSFC
>
>
># Creating Avg.
>
>set fff =3D 00
>while ( $fff <=3D 384 )
>if ( $fff <=3D 12 ) then
>set zero =3D 0
>
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D =
>add(add(add(add(add(TMPKC001,TMPKN001),TMPKP001),TMPKN002),TMPKP002),TMP=
>KN003)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D group1
>GPACK    =3D
>run
>=20
>EOF
>  =20
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D =
>add(add(add(add(TMPKP003,TMPKN004),TMPKP004),TMPKN005),TMPKP005)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D group2
>GPACK    =3D
>run
>
>EOF
>
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D add(group1,group2)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D group3
>GPACK    =3D
>run
>
>EOF
>
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D quo(group3,11)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D group4
>GPACK    =3D =20
>run
>
>EOF
>
>
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D add(mul(sub(group4,273),1.8),32)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D group5
>GPACK    =3D
>run =20
>
>EOF
>
>#Writing the Avg. to the  surface file.
>
>gdgsfc<<stop
>GDFILE=3D$file
>GDATTIM=3D$YY$MM$DD/${cycle}00F$zero$fff
>GVCORD=3Dhght
>GLEVEL=3D2
>GFUNC=3Dgroup5
>SCALE=3D999
>SFFILE=3D2meter_temp.sfc
>SFPARM=3Davrg
>run
>
>stop
>
>
>endif
> =20
> @ fff =3D $fff + 12
>
>  end
>
>
>
>
>gpend
>
>
># This is the start of the standerd devation calculation.
>
>
>set fff =3D 00
>while ( $fff <=3D 384 )
>if ( $fff <=3D 12 ) then
>set zero =3D 0
>
>
>#Converts member from K to F degrees
>
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D add(mul(sub(TMPKC001,273),1.8),32)))
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D a
>GPACK    =3D=20
>run
>  =20
>EOF
>
>#subtracting Avg from member "a"
>
>gddiag<<EOF
>GDFILE   =3D $file
>GDOUTF   =3D $file
>GFUNC    =3D sub(group5,a)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D b
>GPACK    =3D=20
>run
>
>EOF
>
>
># taking the square of "b"
>
>gddiag<<EOF
>GDFILE   =3D $file =20
>GDOUTF   =3D $file
>GFUNC    =3D exp(b,2)
>GDATTIM  =3D $YY$MM$DD/${cycle}00F$zero$fff
>GLEVEL   =3D 2
>GVCORD   =3D hght
>GRDNAM   =3D c
>GPACK    =3D
>run
>
>EOF
>
>
>#Writing the above results to the surface a file.
>
>gdgsfc<<stop
>GDFILE=3D$file
>GDATTIM=3D$YY$MM$DD/${cycle}00F$zero$fff
>GVCORD=3Dhght
>GLEVEL=3D2
>GFUNC=3Da
>SCALE=3D999
>SFFILE=3D2meter_temp.sfc
>SFPARM=3Dtmc1
>run
>
>stop
>
>
># Writing the avg - member to surface file
>
>gdgsfc<<stop
>GDFILE=3D$file
>GDATTIM=3D$YY$MM$DD/${cycle}00F$zero$fff
>GVCORD=3Dhght
>GLEVEL=3D2
>GFUNC=3D b
>SCALE=3D999 =20
>SFFILE=3D2meter_temp.sfc
>SFPARM=3D mins
>run
>
>stop
>
>#Writes the Square of the avg - member
>
>gdgsfc<<stop
>GDFILE=3D/home/met-user/andy/$file
>GDATTIM=3D$YY$MM$DD/${cycle}00F$zero$fff
>GVCORD=3Dhght
>GLEVEL=3D2
>GFUNC=3D c
>SCALE=3D999
>SFFILE=3D/home/met-user/andy/2meter_temp.sfc
>SFPARM=3D stan
>run
>
>stop
>
>
>endif
>
> @ fff =3D $fff + 12
>   end
>
>
>
>gpend
>
>
># Writing the Surface file that we created above to a .txt file
>
># You can and "avrg" if you want to display the avrg.
>
>
>set test =3D dset
>
>sflist<<stop
> SFFILE   =3D 2meter_temp.sfc
> AREA     =3D @SAC
> DATTIM   =3D all
> SFPARM   =3D tmc1;;avrg;mins;stan;slat;slon
> OUTPUT   =3D f/temperature.txt
> IDNTYP   =3D STID
>
>run
>
>stop
>
>exit
>
>------_=_NextPart_000_01C17E71.2620E9E0
>Content-Type: application/octet-stream;
>       name="2m_temp.tbl"
>Content-Disposition: attachment;
>       filename="2m_temp.tbl"
>
>SAC      724830 SACRAMENTO_EXECUTIVE_(ASOS)      CA US  3852 -12150     6 0
>LGA      725033 NEW_YORK_CITY                    NY US  4077  -7398    27 0
>BOS      725090 BOSTON/LOGAN_INTL_(ASOS)         MA US  4237  -7103     9 99
>ORD      725300 CHICAGO/O'HARE_ARPT_(ASOS)       IL US  4198  -8790   205 99
>MSP      726580 MINNEAPOLIS-ST_PAUL_(ASOS)       MN US  4488  -9322   255 99
>SLC      725720 SALT_LAKE_CITY_INTL_(ASOS)       UT US  4078 -11197  1288 99
>DFW      722583 DALLAS/LOVE_FIELD_(ASOS)         TX US  3285  -9685   148 0
>ATL      722190 ATLANTA_INTL_ARPT_(ASOS)         GA US  3365  -8442   315 99
>PHL      724080 PHILADELPHIA_INTL_(ASOS)         PA US  3988  -7525     9 99
>MCI      724460 KANSAS_CITY_INTL_(ASOS)          MO US  3932  -9472   312 99
>PDX      726980 PORTLAND_INTL_ARPT_(ASOS)        OR US  4560 -12260    12 99
>PHX      722780 PHOENIX/SKY_HARBOR_(ASOS)        AZ US  3343 -11202   337 99
>DCA      724030 WASHINGTON/DULLES_(ASOS)         VA US  3895  -7745    98 0
>CVG      724210 CINCINNATI/COVINGTO_(ASOS)       KY US  3905  -8467   267 99
>BHM             BIRMINGHAM_MUNI                  AL US  3357  -8675   192   
>LIT             LITTLE_ROCK/ADAMS_&              AR US  3473  -9223    79
>FAT             FRESNO_AIR_TERM                  CA US  3677  -11972  100
>OKC             OKLAHOMA_CITY(A                  OK US  3540  -9760   397
>IAH             HOUSTON/INTCNTL                  TX  US 2997  -9535    33
>
>------_=_NextPart_000_01C17E71.2620E9E0--
>