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/
><
>****************************************************************************
><
>