Improve some thermo calculation bottlenecks by refactoring how units are handled

[jthielen]

Description Of Changes

I noticed that there have been two major performance bottlenecks caused by the existing approaches to unit handling: iteration in moist_lapse/lcl (#1169) and looping of thickness_hydrostatic in io.gempak's _interp_* functions (#2062). In an attempt to improve this situation, this PR takes the approach of refactoring the relevant thermo calculations to have private versions that only use base units (no pint.Quantity handling), and wrapping those while handling units. No robust benchmarks were evaluated, but this did speed up pytest tests/calc/test_thermo.py on my workstation from about 3.5 seconds to 0.69 seconds (similar to #1980), and @akrherz's test file in #2041 (comment) from 35.88 seconds to 1.78 seconds.

I tried to be careful to not touch any tests in this refactor (other than the fix to the flake8 checker), but do let me know if any tests should be added.

Future work building on this PR could examine if all/most of the calculations should be refactored in this way (which may also reveal some cleaner implementation approaches) and if numba jit/guvectorize could meaningfully accelerate any of these private routines.

@sgdecker, could you evaluate how much performance improvement this gives you relative to your earlier tests in #2062?

@nawendt, these changes caused some failing tests in the GEMPAK reader due to what looks to be marginally different output values. Would you be willing to take a look and see if these differences are significant or not?

Checklist

• Closes thermo.py: (hack) Optimise dt function in moist_lapse by eliminating … #1169, closes snxarray is slow #2062
• Tests added
• Fully documented

[nawendt]

I added a comment to convert_degC_to_K. This function is the reason the tests started failing. It did not account for missing values which were most likely -9999. The reference data has a nan value whereas the decoded soundings ended up having some nonsense values in the same array position. Glad it was an easy fix.

[sgdecker]

On an old laptop, I am going from 3:00 to 0:13 with this branch and my test file. Very nice!

[jthielen]

I wasn't all that happy with the private routine + public wrapper approach...it would get really messy if applied to the whole calculation suite. So, I went back and came up with a decorator-based alternative: https://gist.github.com/jthielen/93ec9fcd8f3892a83215309fe5cda2c6. Doing it this way moves all unit specification into the decorator (which does carry with it the slight issue of default arguments in the signature needing to be in base units and not Quanitities), and leaves the unitless version attached to the parent function on the ._nounit attribute (for use internally).

The existing approach is passing all checks, but let me know if it'd be useful and go back and redo it in the decorator-based way. If going that route, I'd want to clean it up to allow the existing check_units and this new process_units to better share code, and to think through if I'm missing any edge cases in the design. Otherwise, if we want to get these performance improvements in as soon as possible, the decorator alternative can be left to a future refactor when we need to optimize more routines.

[jthielen]

This has now all been rewritten to use the decorator-based approach! Performance improvements from my tests are about the same as before.

[jthielen]

This should be ready for final review once it is adapted after the merge of #2263

[jthielen]

@dcamron I've rebased this on main now that #2263 is in. I'm not on my primary workstation at the moment, so wasn't able to check full lint, test suite, and performance, but at least we can see what CI thinks. Also, should be good enough for a review.

[dopplershift]

We can ignore Code Climate.

[dopplershift]

Wish we had some actual benchmarks in place, but alas.

[dopplershift]

Wish we had a benchmark, but alas.