LFC bug

[aschueth]

I'm trying to correctly implement the virtual temperature correction for a sounding, and calculate CAPE accordingly (http://www.flame.org/~cdoswell/virtual/virtual.html). In summary, you are supposed to apply the virtual temp correction to both the environmental temperature profile, and the parcel profile (based off the uncorrected environmental temperature profile). Then, CAPE/CIN is calculated with those 2 profiles, however, it uses the LCL from the uncorrected temperature profile. This last part is the tricky part. In the LFC function, there is a calculation for the LCL that uses the temperature and profile you give it:

# Compute LCL for this parcel for future comparisons
this_lcl = lcl(pressure[0], parcel_temperature_profile[0], dewpoint_start)

So if you were to give this function the virtual corrected parcel profile, it would be the incorrect LCL. Then, downstream, the LFC and downstream CAPE calculation will be incorrect. I also think this tangentially ties into #461, due to the different parcel path options.

I also stumbled upon this (http://johnrleeman.com/pubs/2017/Leeman_SciPy_Poster_2017.pdf), so I may have interpreted this issue incorrectly and @jrleeman can correct me?

[jthielen]

Thanks for pointing this out and bringing up the physically correct behavior! A few points to reframe the discussion, however, since I would consider this issue as less of a bug, and more an enhancement to permit true handling of the virtual temperature correction (since these functions were built up over the years without virtual temperature being a core consideration).

1. @jrleeman can correct me if I'm wrong, but believe his work in that poster actually predates any LCL-dependence in the LFC calculation (which was first introduced in LFC and EL calculations when LFC = LCL #469)

2. In the case mentioned where virtual temperature is provided for the parcel profile and so an incorrect LCL is calculated, the output LFC is only incorrect if a "natural LFC" above that LCL does not exist (since the LCL only becomes the reported LFC as a fallback, and not in the default case), so this hopefully only impacts a small number of cases

3. EL also internally calculates LCL for an internal check of EL existence, and would similarly need to be adapted like LFC.

In any case, this distinction between where to properly use temperature vs. virtual temperature throughout the stack of parcel computations would be a key thing to factor in to the eventual implementation of #461.

[dopplershift]

My head hurts.

We should definitely do what we can to get it right. I just wonder with some of these things if ignoring effects like entrainment and vertical acceleration (thinking like this twitter thread) aren't dwarfing some of these other effects.

Would also be a fun little experiment to run, which is a bigger effect: 0.5 degree error in your profile measurement or neglecting virtual temperature in your LFC?