Open bjkindia opened 3 years ago
Has anybody found a reasonable workaround for using WRF files in the recent versions of Ferret? I can only work with WRF data using an older classic Ferret version that I have my fingers crossed will not stop working. Current Ferret versions appear to have "developed" beyond being able to use data from the WRF model. This is unfortunate given the number of WRF users, combined with the inability to change the WRF file format because of the many other tools in the weather community that assume the format of the WRF files (warts and all--the format has its issues in terms of ignoring CF conventions).
For more than a decade, Ferret has been my go-to program for plotting WRF output, and I used to recommend it to everybody who would listen because of the ease of use, few number of lines of code needed to get descent plots, etc. Now, I cannot do that because odds are the code won't work for new users when they install a recent version.
Is it possible to have Ferret recognize a WRF file and adjust its format expectations accordingly to work outside of the CF conventions?
The issue that the recent Ferret or PyFerret versions have been trying to address is the lack of full descriptions for coordinate and grid information in the datasets. This isn't unique to WRF files. (See Ferret issue 1046, https://github.com/NOAA-PMEL/Ferret/issues/1046, and other later reports and discussion.)
I downloaded an example dataset wrfout_v2_Lambert.nc, from a link on this page: https://basemaptutorial.readthedocs.io/en/latest/wrf.html
Opening it in an older Ferret version, and looking at "show data", the listing starts as follows (skipping some variables with identical grids):
currently SET data sets:
1> /home/ansley/Downloads/wrfout_v2_Lambert.nc (default)
name title I J K L
TIMES ... ... ... 1:13
LU_INDEX 1:73 1:60 ... 1:13
U 1:74 1:60 1:27 1:13
W 1:73 1:60 1:28 1:13
MU 1:73 1:60 ... 1:13
PB 1:73 1:60 1:27 1:13
FNM 1:27 ... ... 1:13
FNP 1:27 ... ... 1:13
Notice how the dimension of length 27, which should be in the Z direction, is listed in the X direction for variables FNM and FNP. So if one needs to write expressions using multiple variables in the file which have inconsistent directions there will be errors. The more-recent code has logic to create consistent grids, and if it cannot, it issues the error about inconsistent grids.
The dataset uses dimensions but does not include coordinate variables, so the coordinates do not include direction information. Only very limited attempts are made to assign directions to dimensions based on their name. Time is in the T direction, but dimensions in this file including west_east and bottom_top are not given directions.
In Ferret dimensions without an associated coordinate variable are always just the index values, for instance Time = 1, 2, ..., 13; and dimension west_east uses coordinates of 1, 2, ..., 73. One workaround for now would be to add coordinate variables to the dataset, perhaps using NCO operators, and include the attribute axis= "T"; axis="X"; on those coordinate variables.
Another possible workaround is to use NCO to pull out a subset of the dataset containing variables that are relevant to your work and which have consistent grids.
All of that said, I think that there may be a bug in the logic that is attempting to create consistent grids for the dataset. I'll see if I can suggest what could be done there.
This has been asked again, see #134. I have just posted some ideas there. And there is a question on the Ferret Users List where I will also post today's ideas.
The updates in the routine cd_consistent_axis_orient.F address this and other examples of such files. So this will be improved or resolved when there is a new release.
I have wrfout file at one time step and trying to open in ferret. but I am having error like this (below)