Change MET V11.1.0 Point-Stat choices for matched pairs

[jwraby]

I ran Point-Stat V 11.1.0 to verify the surface variable (Z0) skin temperature (TMP-GRIB Code 11) and the temperature at the 2m level (Z2) (TMP-GRIB Code 11). The MPR output file showed that these two variables each had 2 matched pairs. See the following output extracted from the output:

VRBL Unit LVL OBTYPE TOT INDX LAT LON OBS_ELV FCST OBS
TMP K Z2 ADPSFC 2 1 32.58 -106.67 1351.39001 292.7511 298.97754
TMP K Z2 ADPSFC 2 2 32.58 -106.67 1349.39001 292.7511 293

TMP K Z0 ADPSFC 2 1 32.58 -106.67 1351.39001 293.2619 298.97754
TMP K Z0 ADPSFC 2 2 32.58 -106.67 1349.39001 293.2619 293

For the Z2 level there are 2 obs being chosen for matched pairs as follows:
#msg_type s_id valid_time lat lon elv gc level height qty value
ADPSFC MSATWR12 20220705_121500 32.58 -106.67 1349.39 11 869.25781 1351.39 NA 298.97753
ADPSFC MSATWR12 20220705_121500 32.58 -106.67 1349.39 11 869.3 1349.39 NA 293

For the Z0 level the same 2 obs were chosen.

For both levels (Z0 and Z2) the OBS_ELV (height) values for the 2 obs are different because one is for the skin temperature (1349.39) and the other is from the temperature sensor at the 2m AGL level (1351.39). This is not what we would like. We want to verify the skin temperature and the 2m AGL temperature separately. For example see the following matched pairs which provide what we would like:
VRBL Unit LVL OBTYPE TOT INDX LAT LON OBS_ELV FCST OBS
TMP K Z2 ADPSFC 1 1 32.58 -106.67 1351.39001 292.7511 298.97754
TMP K Z0 ADPSFC 1 1 32.58 -106.67 1349.39001 293.2619 293

How can this be done? I can provide the output and related data using the Army file transfer system which requires delivery by email. Thanks.

[j-opatz]

Hi John,

And thank you for your question. I think this might be solved with some more specific parameters passed to Point-Stat at run time, informing MET exactly which observation values are allowed (i.e. thresholds) for checking matched pairs.

But in order to speak confidently on the subject I'll need to take a look at the data and output (as well as a configuration file if you're able to provide one).

You should have my email (John Opatz) from previous interactions in UCAR; let me know if you don't (or if it's easier to submit to one of my colleagues' email like John HG).

[jwraby]

Hi John. Thanks for your response on this. In the past I have sent data to Julie Prestopnik which she forwards to those working on the issue. Let me know if this work for you.

[jwraby]

John - I found your address and the files are uploading now. There is a mix-up in the filenames. Some have "test1" and others have "test2". The reason is that I forgot to edit the output prefix in the config file after previous testing.

[j-opatz]

Hi @jwraby,

And thank you for your patience as I looked into this issue. There's a few paths to potentially achieve what you're seeking, but after conferring with my colleagues, I think I have a first try for you.

It seems like the observation file was created through the use of ASCII2NC? If so, and you have control over the creation of your input observation file, you can alter a few things to make your current levels of Z0 and Z2 work for you.

First, change the message type from its current ADPSFC to a different value, such as MSATWR (to mimic the station ID) or SATEMP. The reason for this change is the logic in MET; when it processes ADPSFC type messages it specifically ignores the vertical values attached to the data, treating them all as "surface". This explains the multiple matched pairs MET is finding when processing the data.

Next, try setting the height column calculation to be [current point's height - elevation]. Doing that will allow you to fully utilize the Z0 and Z2 level settings in the observation fields, as only the skin temperature will have a height of 0 (and will be selected with Z0), and the second observation will have a height of 2 (and will be selected with Z2) .

With both of these changes in place, your example observation lines for the Z2 TMP will change from

#msg_type s_id valid_time lat lon elv gc level height qty value
ADPSFC MSATWR12 20220705_121500 32.58 -106.67 1349.39 11 869.25781 1351.39 NA 298.97753
ADPSFC MSATWR12 20220705_121500 32.58 -106.67 1349.39 11 869.3 1349.39 NA 293

to

#msg_type s_id valid_time lat lon elv gc level height qty value
MSATWR MSATWR12 20220705_121500 32.58 -106.67 1349.39 11 869.25781 2 NA 298.97753
MSATWR MSATWR12 20220705_121500 32.58 -106.67 1349.39 11 869.3 0 NA 293

Do these suggestions make sense to your situation? Please let me know if further explanation is necessary.

If you are unable to control the observation dataset to this level, I can try an alternate path forward for you.

[jwraby]

Hi John. No problem. Yes, the observations file was produced using ASCII2NC. I am involved in a development project aimed at taking raw observations data from meteorological towers ARL has fielded in an array near White Sands Missile Range, NM and averaging this very high temporal and spatial resolution data over a time period which can be used to verify the 15-min WRF-LES forecasts. The averaged data is then reformatted to the MET ascii format to be used as input to ASCII2NC. The file I provided to you contains simulated observations from a single tower.

Thanks for your suggestion to modify the input observation file. This looks very do-able since I control the creation of and data going into the input file. Regarding the changes to the height of the measurement it looks like using height above ground level may resolve this issue for the TMP observations. I will give this a try tomorrow and let you know.

[jwraby]

Hi John. The test I did today was successful! I will send you the output CNT and MPR files, the observation files (text and NetCDF), and the config file. I edited the message type in the config file for the TMP fields to change from ADPSFC to MSATWR.

Based on your understanding of what I am trying to do here, do you see any reason why I could not make the same changes for all the other observations? I'm thinking of changing all message types which are ADPSFC to MSATWR and change the elevations accordingly as you did for the TMP observations. I need to keep the 3 observations which are ADPUPA since I verify the forecasts in those 3 cases on a pressure level.