Comments (4)
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:
-
The user can select if they want 'pressure', 'height_agl', or 'height_msl' as the vertical coordinate.
-
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.
-
In areas where the search is not valid because the lowest model level is above the cloud threshold, a fill value will be used.
-
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.
Related Issues (20)
- Limit to older versions of Python until testing catches up and we can address known issues
- WRF-Python: Plotting variables with different pressure levels and Time
- Add Python 3.11 tests
- naturalearth download
- save slp to netcdf HOT 4
- Error using "pip install wrf-python" HOT 2
- numpy.distutils is removed in python 3.12
- Calculation WRF=4.5.1 HOT 4
- Problem with wrf.interplevel desiredlev input
- Wrong SLP gathered by getvar HOT 5
- ImportError -> from wrf import getvar HOT 3
- PyPI trusted publishing
- WRF-python post-processing wind speed issues HOT 6
- Getvar Returned Large SLP Values Occasionally HOT 1
- Wrf-python package "uvmet10_wspd_wdir"
- wrf.interplevel and wrf.vinterp results in very high values for vertical temperature gradients
- WRF-Python Install - Mac M3 HOT 8
- error when install wrf-python HOT 2
- getvar returns ['GSW' is not a valid variable name]; extract_vars returns [got multiple values for argument 'timeidx'] HOT 3
- Error heppend during the conda install HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wrf-python.