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

20011019: interpolated fsltogem


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 ha
> 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, one
>   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 wondering
>if you have any idea why, or if I should upload the updated fsltogem so you ca
> n
>look it over.
>     I'm starting to wonder if the CAPE is supposed to be zero, except on days
>   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
>****************************************************************************
>