heat_index with list comprehension to address #596

[anissa111]

PR Summary

Closes #596

Right, so what I've done here is switched from using xr.where to handle the adjustments to a (admittedly weighty) list comprehension.

The list comprehension makes it so that the adjustment won't be calculated where the value doesn't meet the adjustment criteria. The adjustment calculation only tries to square root a negative outside of the adjustment criteria, so this eliminates that possibility. I've also added an extra test that makes sure dask works with multi-dimensional inputs.

I am not at all sure that my usage of dask here is ideal, but it does work? If anybody has any suggestions, I'd be happy to hear them.

---

PR Checklist

General

• Make an issue if one doesn't already exist
• Link the issue this PR resolves by adding closes #XXX to the PR description where XXX is the number of the issue.
• Add a brief summary of changes to docs/release-notes.rst in a relevant section for the next unreleased release. Possible sections include: Documentation, New Features, Bug Fixes, Internal Changes, Breaking Changes/Deprecated
• Add appropriate labels to this PR
• Make your changes in a forked repository rather than directly in this repo
• Open this PR as a draft if it is not ready for review
• Convert this PR from a draft to a full PR before requesting reviewers
• Passes precommit. To set up on your local, run pre-commit install from the top level of the repository. To manually run pre-commits, use pre-commit run --all-files and re-add any changed files before committing again and pushing.
• If needed, squash and merge PR commits into a single commit to clean up commit history

[anissa111]

Well dang it, I broke dask.

[kafitzgerald]

I'm a little worried about performance (especially with Xarray/Dask) and readability here.

I did some quick testing of this proposed change with larger arrays and saw some pretty major impacts to performance when using Xarray objects. I've not written a benchmark (yet), but I can work on that. The point being though that I think we should look into other options.

Unfortunately, I don't have a nice clean solution that solves for everything.

I did look into rewriting this as a ufunc last week, but wasn't having much luck avoiding the original issue.

Rewriting the np.sqrt as **0.5 does avoid the warning for xarray object, but not for numpy. This is how MetPy does it and we could potentially filter the remaining warning if that's bothersome. That said, I realize this doesn't address the additional calculations issue, but I'm struggling to come up with something that does and plays well with Xarray and Dask.

[anissa111]

Sigh, yeah I unfortunately agree. I'm going to draft-mode this and go back to the drawing board.

I'm a little worried about performance (especially with Xarray/Dask) and readability here.

I did some quick testing of this proposed change with larger arrays and saw some pretty major impacts to performance when using Xarray objects. I've not written a benchmark (yet), but I can work on that. The point being though that I think we should look into other options.

Unfortunately, I don't have a nice clean solution that solves for everything.

I did look into rewriting this as a ufunc last week, but wasn't having much luck avoiding the original issue.

Rewriting the np.sqrt as **0.5 does avoid the warning for xarray object, but not for numpy. This is how MetPy does it and we could potentially filter the remaining warning if that's bothersome. That said, I realize this doesn't address the additional calculations issue, but I'm struggling to come up with something that does and plays well with Xarray and Dask.