BUG: Fix passing masked arrays to CAPE/CIN calcs

[dopplershift]

Description Of Changes

This is to explicitly fix passing masked arrays to surface_based_cape_cin, but really fixes some low-level helper functions, so this likely fixes all of the CAPE/CIN calculations.

Checklist

• Fixes surface_based_cape_cin fails with masked arrays #1496
• Tests added
• Fully documented

[dcamron]

Looks to me like this is clean and ready to go!

[ghost]

Congratulations 🎉. DeepCode analyzed your code in 3.446 seconds and we found no issues. Enjoy a moment of no bugs ☀️.

👉 View analysis in DeepCode’s Dashboard | Configure the bot

[dopplershift]

Rebased to fix conflict. DeepCode is wrong.

[akrherz]

Peanut gallery here and a day late, two dollars short with my comment, but I am curious this change. The MetPy code base seems to be rather consistent with the style of

blah = values * units.something

This change seems to switch the order to fix this bug, but how does it fix the bug? Should all of metpy switch to that ordering or is it not supposed to matter, which in that case, this fix should not matter? This seems arbitrary :)

[jthielen]

@akrherz Long story short is that right now this is an upstream issue with regards to masked arrays, numpy/numpy#15200, which shows up a lot and so we have to work around it often.

blah = values * units.something

is indeed Pint's canonical way of doing constructing a Quantity, and how it should work, but it breaks if the type of values doesn't properly defer to upcast types like Pint Quantities/Units and instead tries handling the operation itself. I prefer

blah = units.Quantity(values, 'something')

instead of

blah = units.something * values

when values is of a non-cooperative type, but either work, since now Pint is handling the operation.

[akrherz]

Hi @jthielen, thanks. I think that's my point then.

If this is brittle,

blah = values * units.something

and either of the following two are not brittle

blah = units.Quantity(values, 'something')
blah = units.something * values

Then all of Metpy and slack-jawed yocals like me should start using one of the two non-brittle methods?

[dopplershift]

Yes...and no. Yes, because everyone's code will be more likely to work when using netCDF4-python. No, because we really want to the original to work since it maps most easily to our mental models and how we write values with units--and "just" need to fix upstream.

So as usual I end up battling between practicality and my platonic ideal that is just beyond my fingertips.

Or use xarray and it will "just work".

[dopplershift]

I should also add that this has become a much bigger problem because netCDF4-python went from "return masked arrays when necessary" to "return masked arrays always", and a lot of cases that worked fine before now suddenly are now needlessly broken by them.

Edit: not to say that returning masked arrays always was a bad choice (polymorphic returns having nothing to do with what you pass in is confusing to the users), just we now have people dealing with masked arrays when they don't need them. I'm of the opinion that masked_arrays from netCDF should always have been opt-in behavior.

[jthielen]

I should also add that this has become a much bigger problem because netCDF4-python went from "return masked arrays when necessary" to "return masked arrays always", and a lot of cases that worked fine before now suddenly are now needlessly broken by them.

Edit: not to say that returning masked arrays always was a bad choice (polymorphic returns having nothing to do with what you pass in is confusing to the users), just we now have people dealing with masked arrays when they don't need them. I'm of the opinion that masked_arrays from netCDF should always have been opt-in behavior.

And given how poorly maintained MaskedArrays seem to be within NumPy (with some suggestions even to move it to a third-party package), it's even more of a headache.

[akrherz]

Thanks @dopplershift for indulging me here. I have seen a couple of other projects now emitting warnings for RHS multiplication support for their objects for similar reasons to this I think and was curious.