Pulling out of #582

Yeah, I agree we shouldn't do this because, at the least, our users will still see it. From some DMs, I actually think this is an unintended behavior "bug" and I'm looking into it currently.

In short, in heat_index, we apply some adjustments to the values depending on the value of a couple other variables. The adjustment itself should never attempt to square root a negative, but the function (xr.where), calculates all the adjustments and then applies them where the filter passes instead of finding where the filter passes and then calculating the adjustment. If that makes sense?

geocat-comp/geocat/comp/meteorology.py

Lines 121 to 134 in 2fbef4e

	# adjustments
	heatindex = xr.where(
	np.logical_and(relative_humidity < 13,
	np.logical_and(temperature > 80, temperature < 112)),
	heatindex - ((13 - relative_humidity) / 4) * np.sqrt(
	(17 - abs(temperature - 95)) / 17), heatindex)
	heatindex = xr.where(
	np.logical_and(relative_humidity > 85,
	np.logical_and(temperature > 80, temperature < 87)),
	heatindex + ((relative_humidity - 85.0) / 10.0) *
	((87.0 - temperature) / 5.0), heatindex)
	return heatindex

We're doing this partially because of dask compatibility and partially because it's the cleanest way to accept n-dimensional data of numpy/list/xarray types.

We could theoretically filter the warnings here, but it bothers me that we're doing a bunch of unnecessary calculations.

Originally posted by @anissa111 in #582 (comment)