wet() bug fix and workaround for bad tsfco

[SamuelTrahanNOAA]

Fixes this problem:

• global_nest_v1 suite: infinite cumulative surface upwelling long-wave flux ufs-weather-model#2547

It was caused by missing values (-1e+20) for sea surface temperature on wet points in input data. (Wet points are points where the CCPP wet array is true, thus indicating the surface is at least partly water.) There's a bug fix and a workaround:

1. Bug fix: In certain situations, the wet array can be mistakenly true when it should be false due to the location being 100% ice. An "else" statement corrects this.
2. Workaround: If the input sea surface temperatures (tsfco) are invalid on a wet point, the lowest model level temperature is used instead.

There is no other temperature available on those points that can reasonably be used as a sea surface temperature. The lowest model level temperature may not be a perfect analogue for the sea surface temperature, but it'll be more realistic than -1E+20 K.

[GeorgeGayno-NOAA]

Is UFS_UTILS providing bad input data - bad orography or a bad coldstart initial condition?

[SamuelTrahanNOAA]

Is UFS_UTILS providing bad input data - bad orography or a bad coldstart initial condition?

The tsfco comes from the surface files, while the land masks and fractions come from the orography files. There is clearly a disagreement between the two.

I cannot be certain the problem comes from a bad UFS_UTILS. Our UFS_UTILS was modified by @NingWang325. Thus, I don't know if the problem is with the original UFS_UTILS or with Ning's modifications, or nither.

It's also possible the person running this (Sijie Pan; don't know his github handle) mixed surface and orography files from different versions of UFS_UTILS. Monday, I carefully regenerated everything from Ning's version so Sijie can rerun with a set of files that are known to be consistent. Perhaps when he does that, all our problems will vanish.

[climbfuji]

Thanks for fixing this. I will note that if we were strict about CCPP requirements, we wouldn't allow writing to stdout and stderr in schemes, but given that we have never enforced that rule, there is plenty of precedence for writing to stdout/stderr in schemes, and we don't have a great alternative at the moment (errmsg), this is fine. I guess all I am trying to say is that I thought about the rules and decided for myself that it is ok to ignore them for now ;-)