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

20011214: Bulk Richardson

Diana,
The fsltogem fix did solve the problem with the newer soundings 
where the temperature and winds were provided at different levels.
The previous problem resulted from trying to integrate over levels
where the temperature was missing. I'm glad that the fix has worked for you.

For Bulk Richardson:
BRCH = CAPE / ( 0.5 * U**2 )
C*              U     = magnitude of shear ( u6 - ub, v6 - vb )         *
C*              ub,vb = average u,v in the layer SFC - 500 m            *
C*              u6,v6 = average u,v in the layer SFC - 6000 m           *

The number can go to Infinity or very large ******** if the U^2 term
is very small; with large CAPE (typical in the south) and low wind shear,
that would be a possibility. But, we can always look at a particular sounding 
to see. Feel free to send me the snlist output with all levels of data.

Note that you have control using the "!" modifiers to change the layers that
BRCH is using (the default is 500 and 6000).  
From the "phelp stndex" houtput in snlist:

      The depth for the layer averages may be specified
      preceded by a ! in the user input.  For example, BRCH!1000!8000
      instructs the program to average over a mixed layer 1000 meters deep
      and lower tropospheric layer 8000 meters deep.

So, you can examing your sounding and see if winds are particularly light
or missing and possible change the calculation.

Steve Chiswell
Unidata User Support



>From: <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200112141700.fBEH0RN09930

>
>Hi Steve,
>   Just one question about the Bulk Richardson Number calculations.   For
>a lot of the stations, esp. in the deep south, I'm getting wild values
>for the Bulk Richardson number (like 17000, Inf, or "********").  I know 
>that the Bulk Richardson # will be high if the wind shear component is 
>very low, but THAT high?  Just wondering if this is a mistake in the
>   calculations or if these are reasonable.
>
>
>Thanks,
>Diana
>
>
>
>Diana DeRubertis
>PhD Candidate
>Dept. of Geography
>University of California at Berkeley
>
>From address@hidden Fri Dec 14 09:55:31 2001
>Received: from socrates.Berkeley.EDU (socrates.Berkeley.EDU [128.32.25.13])
>       by unidata.ucar.edu (UCAR/Unidata) with ESMTP id fBEGtVN09755
>       for <address@hidden>; Fri, 14 Dec 2001 09:55:31 -0700 (MST)
>Organization: UCAR/Unidata
>Keywords: 200112141655.fBEGtVN09755
>Received: (from dianamd@localhost)
>       by socrates.Berkeley.EDU (8.11.3/8.10.2) id fBEGtVO26244;
>       Fri, 14 Dec 2001 08:55:31 -0800 (PST)
>Date: Fri, 14 Dec 2001 08:55:31 -0800 (PST)
>Message-Id: <address@hidden>
>From: <address@hidden>
>To: address@hidden
>Subject: update: interpolated fsltogem
>
>
>Hi Steve,
>   This is in response to your response back in October.  Sorry for not gettin
> g
>   back to you earlier.  I checked the CAPE values against the LIFTED INDEX
>values in several files and found that you were right....all of the CAPE 
>observations of zero corresponded measurements of positive LIFTED INDEX.
>However, after getting further into the research, I discovered that this was
>   not the case with observations from 1980-97. 
>Anyway, the new fsltogem that you wrote corrected that problem (I ran it
>on all 50 or so stations), so all is
>well.  I'm including an example of this prob. below for your references.
>I'm not sure if every single station suffered fr. this, but all of the ones
>I had examined to that point (6 or 7) registered zeroes for most CAPE 
>calcuations for 1980-97, even with negative LI.
>
>Bottom line, there are a lot of missing obs (or something going on) in the fsl
>data in later decades, and your new program corrects it.    
>
>
>Example fr. Athens, GA (72311)
>Summer season- June 1 to August 31
>
># days (out of 92) with negative Lifted Index
>
>1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 
>   47   60   65   72   72   74   68   58   65   59   56   49   67   53   56
> 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 
>   51   50   68   68   55   55   65   56   51   55   55   66   59   75   64
> 1986 1987 1988 1989 1990 1991 1992 1993 1994 
>   53   65   61   73   63   67   65   70   71
>
># days with positive CAPE
>
> 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 
>   65   83   78   79   88   85   83   78   78   87   85   82   78   78   75
> 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 
>   71   63   85   82   81   76   77   82   67   70    8    3   11    6    4
> 1986 1987 1988 1989 1990 1991 1992 1993 1994 
>   11   13    8   11   10    3    2    0    4
>
># days with positve CAPE after correcting with new fsltogem:
>
>1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 
>   65   83   78   79   88   85   83   78   78   87   85   82   78   78   75
> 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 
>   71   63   85   82   81   76   77   82   67   71   74   82   76   87   80
> 1986 1987 1988 1989 1990 1991 1992 1993 1994 
>   66   76   74   86   81   82   77   83   82
>
>Thanks! 
>Diana
>------- Start of forwarded message -------
>Organization: UCAR/Unidata
>Keywords: 200110221727.f9MHRa119264
>To: address@hidden
>cc: address@hidden
>Subject: 20011019: interpolated fsltogem 
>In-reply-to: Your message of "Fri, 19 Oct 2001 07:04:39 PDT."
>             <address@hidden> 
>Date: Mon, 22 Oct 2001 11:27:35 -0600
>From: Unidata Support <address@hidden>
>Content-Length: 4478
>
>
>
>Diana,
>
>The updated fsltogem fixed the problem with the input data where additional 
>wind levels without temperature and dewpoint were truncaating the
>stability calculations.
>
>I verified this on the previous data  time you sent me.
>
>CAPE values will be zero if there is no positive area in the sounding.
>A quick sanity check would be to look at the "LIFT" value.
>If LIFT is negative, then you must have a non-zero (positive)
>CAPE value. CAPE is a quantity that is computed from the integrated
>area of the sounding where a lifted parcel would be warmer than the 
>environment. That is, CAPE values are only 0 or positive.
>
>If you have a time/station where you suspect that you should be seeing
>non-zero CAPE, please do send the input data to me and I will
>see if there is any lingering problem.
>
>Steve Chiswell
>Unidata User Support
>
>
>>From: <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200110191404.f9JE4o127203
>
>>
>>Note:  this message is intended for Steve Chiswell
>>
>>
>>Hi Steve,
>>   Remember me?  Sorry to contact you about the Gempak program again.  I've h
> a
>> d
>>a long hiatus in my research due to a cross-country move this summer.  Do you
>>   remember the revised fsltogem program that you posted on your ftp site, on
> e
>>   that interpolated missing values in the sounding data?  This was designed 
> t
>> o
>>correct the large number of zero values calculated for the CAPE and Bulk
>>Richarson Number by STNDEX.  To make a long story short, I've closely checked
>>some of the new results (I only ran it for a few stations), and each value is
>>   exactly the same as my previous results.  Primarily zeroes.  Just wonderin
> g
>>if you have any idea why, or if I should upload the updated fsltogem so you c
> a
>> n
>>look it over.
>>     I'm starting to wonder if the CAPE is supposed to be zero, except on day
> s
>>   of strong convection, b/c I certainly see a lot of high values during the
>>spring and summer months, and at stations like Key West, FL.
>>
>>Thanks for your time,
>Diana DeRubertis
>>
>>
>>PhD Candidate
>>Dept. of Geography
>>University of California, Berkeley
>>
>>______________________________________________
>>Organization: UCAR/Unidata
>>Keywords: 200105242054.f4OKsIp09024
>>To: address@hidden
>>cc: address@hidden
>>Subject: 20010521: 20010518: 20010517: cape, bulk richardson
>>Date: Thu, 24 May 2001 14:54:18 -0600
>>From: Unidata Support <address@hidden>
>>
>>
>>Status: RO
>>
>>Diana,
>>
>>Since you said you would have to recreate the .gem files anyway, I
>>rolled in the duplicate level checks and missing level interpolations in
>>to the fsltogem program so that you won't have to make any changes
>>in your current setup.
>>
>>You can get the updated fsltogem program in the ~gbuddy/nawips-5.6/binary/cal
>>directory on ftp.unidata.ucar.edu. Login is still the same:
>>login: gbuddy
>>password: XXXXXX
>>
>>Remember to ftp the fsltogem program in binary mode. Once you have
>>downloaded the program, place in the $NAWIPS/bin/sol directory of the
>>gempak tree you already have. Ensure that the binary is executable
>>with: chmod 755 fsltogem once you have placed the file in the
>>executable directory.
>>
>>I would suggest trying it out on a single year first, such as the
>>1997 Topeka data set, and then running snlist to verify that
>>your CAPE and BRCH values are as you expect.
>>
>>Good luck,
>>
>>Steve Chiswell
>>**************************************************************************** 
>>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/      
>>****************************************************************************
>>
>
>- ----------------------------------------------------------------------------
>------- End of forwarded message -------
>