Wind speed derivation from u/v in all tools and use in verification?

[mpm-meto]

There seems to be some inconsistency in the ability to derive wind speed from u/v and perform verification on the result across tools. It may just be for netcdf and it does work for GRIB. For netcdf input PointStat/GridStat setting is_u_wind=TRUE and is_v_wind=TRUE works. It appears as though for other tools (MODE and MTD tested so far) it does not, though the specification of the var names, levels and options is essentially the same. These tools just proceed to apply the thresholds to VAR1 and VAR2 separately. It is no hassle to compute wind speed first and then feed that into the tools or one could use some python embedding as well but it would be good to have consistency across tools if that is a possibility. The key one is setting the thresholds for the derived wind speed, for example, because that is the quantity we're after from a verification perspective. It may be the case that the thresholds for the derived quantity are different to VAR1 and VAR2. It's not clear how this is accommodated, unless you specify the thresholds you want (even if the are not appropriate) in the VAR1/VAR2 threshold list. Is there a better way of doing this too? In essence, when one specifies is_u_wind and is_v_wind VAR1 and VAR2 may be irrelevant. Also, in some ways specifying the thresholds under VAR1 and VAR2 may not be that obvious that they will be applied to the derived quantity... there is some ambiguity also, even where the is_u_wind/is_v_wind switch is available.

FCST_VAR1_NAME = x_wind
FCST_VAR1_LEVELS = "(,)"
FCST_VAR1_OPTIONS = set_attr_level="Z10"; is_u_wind=true
OBS_VAR1_NAME = UGRD
OBS_VAR1_OPTIONS = set_attr_level="Z10"; is_u_wind=true
OBS_VAR1_LEVELS = Z10
FCST_VAR2_NAME = y_wind
FCST_VAR2_LEVELS = "(,)"
FCST_VAR2_OPTIONS = set_attr_level="Z10"; is_v_wind=true
OBS_VAR2_NAME = VGRD
OBS_VAR2_OPTIONS = set_attr_level="Z10"; is_v_wind=true
OBS_VAR2_LEVELS = Z10

FCST_VAR?_THRESH = [>=7, >=13]
OBS_VAR?_THRESH = [>=7,>=13]

[CPKalb]

Hi:

To get derived wind speed from any of the MET tools, you have to specify the variable WIND, even if it is not an actual variable in your GRIB file. So, thresholds for derived wind speed would go with the variable WIND, rather than with your x_wind or y_wind above. In the case you have listed above, you would need to add a third variable that looks something like the following:
FCST_VAR3_NAME = WIND
FCST_VAR3_LEVELS = Z10
FCST_VAR3_THRESH = >=7, >=13

This way, the thresholds for the derived wind speed are separate from any thresholds for x_wind and y_wind. Currently, deriving wind speed is only available with GRIB1/GRIB2 files, but is not supported for netCDF. This issue documents changes that would expand the capability to derive wind speeds to netCDF files. However, it is not fully implemented.

In terms of making consistency across tools, I'll have to contact some of the developers over here to get more information about wind in MODE and MTD.

Christina

[mpm-meto]

Thanks @CPKalb. There is some support for netcdf as we do use it as shown by the grid_stat (or point_stat) example above but this netcdf support does not appear to have been pulled through to all tools. It is triggered by this is.u.wind=TRUE and is.v.wind=TRUE.
Out of curiosity would you still have to specify VAR1 and VAR2 as well or could you just specify WIND without UWIND and VWIND?

[CPKalb]

If you have a GRIB1/2 file and the variables are named UGRD and VGRD, you can just specify WIND without also specifying the u and v wind variables. However, if your wind variables are named something else, then this doesn't work. A new GRIB1/2 table could be set up to get around this issue.

[CPKalb]

I'm linking a document which provides some information regarding MODE and vector fields (like wind). Chapter 8 discusses this in detail.

Christina

[mpm-meto]

Thanks. This is a report I haven't seen and a useful additional reference.

We don't have grib. All our files are netcdf. The wind variables are called x_wind and y_wind. The support that has been added to PointStat and GridStat is the added flag is.u.wind and is.v.wind which tells the MET code that it should derive wind speed (aka WIND for grib). [The example above is a mixed one which I grabbed from an operational config which uses ECMWF analyses. These are in grib, so that the OBS_VAR*_NAME=UGRD/VGRD would work as you suggest. Our forecasts/analyses will always be netcdf.]

Therefore my suspicion is that these is.u.wind and is.v.wind flags have not made it into other tools, and means that to use wind speed it needs to be derived before using MODE and MTD.

[CPKalb]

Wind derivation support from netCDF files is not available in MET at this time, but is planned as documented in the issue mentioned above. The capability is not available in MODE or MTD. The only way to get wind speed from a netCDF file into MODE is to compute wind speed either inside a python embedding script or by computing it first and writing to a file that MET can read.

The is_u_wind and is_v_wind flags are actually designed to support the vector output lines from Point-Stat and Grid-Stat. Specifically, they are useful for outputting the VCNT, VL1L2, and VAL1L2 lines. Grid-Stat and Point-Stat are the only tools that output those types of lines. I'm talking to one of our software engineers to get more information about this and will provide more information after we do a bit of testing.

Christina

[CPKalb]

Hi:

We did some testing of this on our end. When reading a netCDF file into Grid-Stat and setting is_u_wind and is_v_wind to true for the correct variables, we are not able to get a derived wind speed. We do get the vector statistics output. These lines have a variable name of UGRD_VGRD, and a line type of VL1L2, VCNT, or VAL1L2. This output is different from a derived wind speed which would have the variable name WIND. I've attached two files. One was ran on a netCDF file and the other GRIB. You can see the WIND line output from the GRIB data is absent in the file from netCDF data. In both configuration files I'm specifying the U and V wind components, but also WIND to get a derived speed, using WIND as a variable mentioned above. WIND is not an actual variable in either file. I've attached the configuration files as well for reference.
grid_stat_CFDDA_vs_CFDDA_wind_test_netcdf_000000L_20050101_000000V.stat.txt
grid_stat_WRF_vs_WRF_wind_test_grib_000000L_20170613_000000V.stat.txt
GridStat_wind_test_netcdf.conf.txt
GridStat_wind_test_grib.conf.txt

Deriving wind speed from netCDF files is currently unavailable in all MET tools. The is_u_wind and is_v_wind flags do not derive wind speed, but rather are applicable to the vector statistics output lines (VL1L2, VCNT, VAL1L2). The only way to get a derived wind speed from a netCDF file is to compute it either using a python embedding script or by some other pre-processing. We do plan to expand this capability moving forward as documented in the existing issue.

Another point of note is that the only MET tools that will accept the is_u_wind and is_v_wind flags are those that compute vector statistics, Grid-Stat and Point-Stat.

Christina

[CPKalb]

Hi:

It's been some time since there was any discussion on this question. Did the information above help answer the questions? If so, please mark a comment as the answer so this question can be closed.