<p>Your screenshot lists the raob as station 72357 on 2013-06-01 00Z.  Station 72357 is OUN and the sounding for that day time is available at the <a href="http://www.spc.noaa.gov/exper/soundings/archive/13060100_OBS/" rel="noreferrer">SPC sounding archive</a>.</p>

<p><img src="https://i.sstatic.net/TWRb9.gif" alt="enter image description here"></p>

<p>The SPC sounding analysis shows 3351 J kg$^{-1}$ CAPE and -76 J kg$^{-1}$ CIN for surface parcels.</p>

<p>My speculation for your anomolous non-physical values of CAPE and CIN is that the algorithm used in that software perhaps doesn't handle the lack of stratopheric data well.  The calculation of CAPE is the parcel buoyancy integrated from the level of free convection (LFC) to the equilibrium level (EL).  This sounding has no EL because the temperature data stops before the tropopause and never increases to equal the temperature of the lifted parcel.  A naive algorithm that does not take this into account would have issues calculating the CAPE and potentially produce undefined output.  I think that is the case in the software in your screenshot.</p>

CC BY-SA 4.0
2019-10-29T13:42:25.273Z
What would the correct recourse for the s/w be in this case ?
Waslap
CC BY-SA 3.0
2014-12-18T02:39:06.270Z
2014-12-18T05:12:31.423Z
2014-12-18T05:12:31.423Z
casey
<p><img src="https://i.sstatic.net/O0m3k.png" alt="http://i.imgur.com/ZXSI69B.png"></p>

<p><a href="https://i.sstatic.net/j41Qf.png" rel="nofollow noreferrer">This sounding</a> is from 2 hours after the 2.6 mile wide <a href="http://www.srh.noaa.gov/oun/?n=events-20130531-elreno" rel="nofollow noreferrer">El Reno tornado on May 31 2013</a>.</p>

CC BY-SA 3.0
2015-10-31T14:58:38.007Z
The RAOB Program (www.raob.com) does not have this CAPE calculation limitation and properly calculates CAPE for all soundings.
John Shewchuk
CC BY-SA 3.0
2014-12-17T15:29:11.990Z
Can you post the raw sounding data?  Looks like a software issue (non-physical).
casey
CC BY-SA 3.0
2014-12-17T16:17:35.447Z
I would, but my laptop stopped working a few momths after I took this screenshot.l, but I remember opening this file in Bufkit and it came out as 0 for the CAPE and CIN.
Kaz
<meteorology><radiosounding><mesoscale-meteorology>
What's with this anomaly in this sounding (the CAPE and CIN readings)?
Kaz
# What's with this anomaly in this sounding (the CAPE and CIN readings)?

(Asked by: username_0 on 2014-12-17)

![http://i.imgur.com/ZXSI69B.png](https://i.sstatic.net/O0m3k.png)

[This sounding](https://i.sstatic.net/j41Qf.png) is from 2 hours after the 2.6 mile wide [El Reno tornado on May 31 2013](http://www.srh.noaa.gov/oun/?n=events-20130531-elreno).

**Tags:** meteorology, radiosounding, mesoscale-meteorology

> **Comments:**
> **username_2**: Can you post the raw sounding data?  Looks like a software issue (non-physical).  
> **username_0**: I would, but my laptop stopped working a few momths after I took this screenshot.l, but I remember opening this file in Bufkit and it came out as 0 for the CAPE and CIN.  
> **username_1**: The RAOB Program (www.raob.com) does not have this CAPE calculation limitation and properly calculates CAPE for all soundings.  

---

## 1 answers

### Answer by username_2 on 2014-12-18. Score: 7

Your screenshot lists the raob as station 72357 on 2013-06-01 00Z. Station 72357 is OUN and the sounding for that day time is available at the [SPC sounding archive](http://www.spc.noaa.gov/exper/soundings/archive/13060100_OBS/).

![enter image description here](https://i.sstatic.net/TWRb9.gif)

The SPC sounding analysis shows 3351 J kg$^{-1}$ CAPE and -76 J kg$^{-1}$ CIN for surface parcels.

My speculation for your anomolous non-physical values of CAPE and CIN is that the algorithm used in that software perhaps doesn't handle the lack of stratopheric data well. The calculation of CAPE is the parcel buoyancy integrated from the level of free convection (LFC) to the equilibrium level (EL). This sounding has no EL because the temperature data stops before the tropopause and never increases to equal the temperature of the lifted parcel. A naive algorithm that does not take this into account would have issues calculating the CAPE and potentially produce undefined output. I think that is the case in the software in your screenshot.

> **Comments:**
> **username_3**: What would the correct recourse for the s/w be in this case ?  

---

