Odd cloudfrac diagnostic output in regions with high terrain about wrf-python HOT 4 CLOSED

Thank you for the bug report. If possible, can you FTP your data file following the instructions here:

http://wrf-python.readthedocs.io/en/latest/support.html#submitting-files

After you upload the file, you'll need to tell me the name of the file so I can pull it down.

The Fortran code came from the WRF team, but it looks like they use pressure values to determine low-mid-high clouds. It should probably be modified to use height in AGL instead, which would eliminate the need for missing/masked values. But, that will break backwards compatible behavior.

from wrf-python.

No problem. The filename is wrfout_d02_1987-10-01_00:00:00. It's a slightly different file (same geographic domain and model configuration, different time), but the same problem is apparent.

I believe cloud levels are typically defined either by altitude or pressure rather than height AGL, but I'm not super familiar with the history of how these diagnostics were defined and the needs of the user base. Not sure what the best approach might be.

from wrf-python.

Thank you for the file. In terms of observations, I believe clouds are reported as AGL, since it's usually from the view point of the observer. Currently the algorithm uses pressure thresholds, which is why you're getting that weird behavior, since you're really seeing impacts of terrain height. The original author of the Fortran code has moved on from NCAR, so what I will probably do is allow the user to specify whether they want their low, mid, and high thresholds to be in terms of pressure thresholds, height AGL thresholds, or height MSL thresholds. By default, it will use the pressure thresholds for backwards compatibility. As for when this actually gets implemented, it may not be for a while since I am currently busy with the PyNIO port to python 3.x.

from wrf-python.

Here's an update on this. First, the bug is a little more severe than I thought. In the vertical search for the cloud layers, the cloud level 'k' value is never initialized, so in mountainous regions where the surface is higher than the cloud layer, you will either get a random value or a previous value. So, the behavior is non-deterministic in places.

Second, the file that you sent me has a maximum RH of 63%, which isn't high enough to trigger any noticeable cloud fraction values for this algorithm. If this were working correctly, all values should have been 0 (note: if plotting with cartopy, it will crash with an obscure empty bounding box error). Do you happen to have the same file you used when creating the graphics above?

For the next release of wrf-python (and eventually NCL), the new behavior will be:

1. The user can select if they want 'pressure', 'height_agl', or 'height_msl' as the vertical coordinate.

2. The user can select the low, mid, and high cloud thresholds based on the vertical type in 1. For 'pressure', the default thresholds are 970 mb, 800 mb, and 450 mb. For 'height_msl' or 'height_agl', the default thresholds are 300 m, 2000 m, and 6000 m, which is similar to what I've found on the internet from WMO on this.

3. In areas where the search is not valid because the lowest model level is above the cloud threshold, a fill value will be used.

4. The default vertical type will still be 'pressure' so that old scripts will run, but the inclusion of fill values in the output may break backwards compatibility depending on how the output is used.

For now, I'd advise people not to use this algorithm until the next release of wrf-python is out.

from wrf-python.