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.
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-- >