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

FW: 20011130: 20011130: Computing the standard deviation

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.

Steve,
I finally figure out how to make that .gem file smaller.
The file should be attached. 
The unfortunate problem is that the truncating problem did not go away over
the weekend.  In our phone call last week you also requested an example of
the gdgsfc

gdgsfc<<stop
GDFILE=/home/met-user/andy/$file
GDATTIM=$YY$MM$DD/${cycle}00F$zero$fff
GVCORD=hght
GLEVEL=2 
GFUNC= c
SCALE=999
SFFILE=/home/met-user/andy/2meter_temp.sfc
SFPARM= plus
run

stop

So, as it stands the problem lies in how gddiag is storing "b" in .gem.
The problem is when  we taking this small number "b" from the  Avg - "the
member" calculation and try to square it this will give us the variance. 

We know that "b" is correct calculation 

I'm not really sure what else to add, I just hope that you having the .gem
file helps.
Thanks,
Andy


-----Original Message-----
From: Siffert, Andy 
Sent: Monday, December 03, 2001 8:33 AM
To: 'Unidata Support'
Subject: RE: 20011130: 20011130: Computing the standard deviation 


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