NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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--
>