NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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 >**************************************************************************** >