Point-Stat error verifying UGRD and VGRD winds

[WillySedlacek-16WS]

Good afternoon! I'm encountering an error while attempting to run verification of UGRD and VGRD winds in Point-Stat using METplus. I had previously done this using MET without any difficulties, and my MET vs. METplus point-stat config file settings appear to be identical. This is the error message I'm receiving:

ERROR : do_vl1l2() -> unequal number of UGRD and VGRD pairs (8 != 10)

I'm using version 12.0.0.

Thank you,
Willy

[jprestop]

Hi @WillySedlacek-16WS. Thank for your question.

Can you please let us know the organization or institution with which you're affiliated, so we can add a "requestor" label to this discussion to help us keep track of the support we provide?

Could you please provide the command line you're running for this case? Could you please also provide any configuration files you're using for this run in one of the ways suggested in this post: How to Send Us Data (REVISED JAN 2025) #954? And if it's not a large case, could you please provide the data files as well so that we can attempt to reproduce this error?

[WillySedlacek-16WS]

Hi, Julie! I'm with the 16th Weather Squadron at Offutt AFB. I've attached the config file I'm using to this post.

The command line I'm using is a bit complicated. We're using an in-house python-based wrapper around METplus, so the command is unique to that wrapper and not typical of what would be used for METplus.

I'm also not sure that I can provide the data files, due to Air Force cybersecurity restrictions. I can check with my leadership, though.

galwem_0p25_deg_prepbufr.txt

[JohnHalleyGotway]

Hi @WillySedlacek-16WS. Thanks for sending along your configuration file. I have a suggestion for how you could modify it, but first let me explain the error you're getting.

Wind vectors are typically defined in model output by their U (east-west) and V (north-south) components. While you could verify U and V separately, as individual scalars, we typically choose to verify them as U/V vector pairs. The forecast U/V pair is compared to the observed U/V pair at each verifying grid or point location, and the results are aggregated together and written to the VL1L2 output line type (and VAL1L2 line type if climatology data is provided to define anomalies). The corresponding statistics are written to the VCNT line type.

The complicating factor is that U and V are requested SEPARATELY in the MET config files. So Point-Stat needs to figure out which U-wind verification tasks correspond to which V-wind verification tasks. And once it does, it double-checks that it has the same set of "U's" and "V's". The error you're seeing comes from that check on line number 1701 of point_stat.cc. If we have differing numbers of U's and V's, the U/V pairs are not well defined.

So why is this happening?

One reason could be that for some stations, you have point observations of U, but not V, or vice-versa. But I doubt that's what's happening here. Instead, I think your use of the mpr_thresh option is tossing out some of the U's and some of the V's... but not the same ones, and that's causing the mismatch in counts.

Is see this in your config file:

mpr_column = [ "ABS(OBS-FCST)" ];
...
      {
        convert(x) = x*1.94;
        name       = "UGRD";
        level      = ["P1000", "P925", "P850", "P700", "P500", "P400", "P300", "P250", "P200", "P150", "P100", "P70", "P50", "P30", "P20", "P10", "P7", "P5", "P3", "P2", "P1"];
        mpr_thresh = [ >5 ];
      },
      {
        convert(x) = x*1.94;
        name       = "VGRD";
        level      = ["P1000", "P925", "P850", "P700", "P500", "P400", "P300", "P250", "P200", "P150", "P100", "P70", "P50", "P30", "P20", "P10", "P7", "P5", "P3", "P2", "P1"];
        mpr_thresh = [ >5 ];
      }

So you're telling Point-Stat to only compute statistics for points where the absolute value of the observation minus forecast difference exceeds 5. But that filtering logic is applied SEPARATELY to the U and V components. Based on the error message, you're finding 8 UGRD pairs that meet this criteria and 10 VGRD pairs that do.

So what are your options?

1. You could disable the vector output by setting VL1L2, VAL1L2, and VCNT to NONE in the output_flag. Then you should get scalar stats for the U and V components separately and skip right over the vector logic.
2. Instead of requesting UGRD and VGRD, you could request WIND (for wind speed) and Point-Stat will automatically derive wind speed from the U/V components and then process it as a scalar. The mpr_column and mpr_thresh logic would work fine on a scalar field of wind speed. The complication is that you'd also need point observations of wind speed to be present in your data stream since MET won't derive those for you.
3. Instead of using mpr_thresh for UGRD and VGRD, you could switch to wind_thresh. However that logic is different. It does filter the U/V pairs, but only by the forecast and/or observed wind speed... not their difference. Generally speaking, wind_thresh is useful for computing stats that meet some minimum wind speed criteria for which the wind direction is well-defined. But it's not useful for filtering out outliers with large differences.

If this functionality, being able to isolate and verify wind vector outliers is important to the USAF, we could brainstorm how to provide that functionality in a future release.

Please let me know how this works out.

[WillySedlacek-16WS]

John, thank you for the very detailed response. I apologize for my delay in replying. Things have been a bit crazy recently with the return to working in the office.

I didn't have the best understanding of how MET handles wind vector verification, and you cleared up a lot of my uncertainties. Ultimately, I was confused and using mpr_thresh when I actually should have been using wind_thresh for what we're trying to do. It was a foolish mistake on my part.

I think we're in good shape now with this correction applied.

[JohnHalleyGotway]

Oh that's great. Thanks for following up. I'll go ahead and close this discussion and lock it to prevent future posts. But please feel free to start a new discussion if more issues or questions arise.