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.

[j-opatz]

John,

Great to hear the suggestion worked! I took a look at your output and can see the changes helped remove the higher elevation observations.

As long as you don't intend to rely on the simplified logic for level matching that ADPSFC provides (as well as SFCHP and MSONET, as defined in message_type_group_map), changing the message types for the remaining variables (minus the ADPUPA ones) shouldn't present any problems.

Note that by doing so, any later stratification you wish to accomplish (such as with Stat-Analysis) would need to be done by column values other than OBTYPE (since all of the rows aside from the 3 ADPUPA values would be MSATWR); not a big deal since you can use the variable name or level, but something to be aware of.

[jwraby]

Thanks for your comments about the possible consequences of using this specialized message type. This project is very focused on the use of the observations from an array of 12 towers initially with future projects anticipated for the entire array of 61 towers located in complex terrain. We can control this data and don't expect to bring any other types of obs into play in these very small model domains with sub-kilometer grid spacing. The WRF-LES simulations are focused on atmospheric structures and flows of very small spatial and temporal scales which require a dense network of observations to hopefully capture some of these phenomena and enable an assessment of the skill of the model.

I was able to do another test with Point-Stat where I did change the message types of all the observations (except for the ADPUPA values) and the results confirmed what you said and were identical to those I got with the previous test which I sent to you yesterday. With the observations formatted this way, it seems more appropriate for tower data where there are 3 different levels of measurements for each tower. Having heights referenced to the local ground level (AGL) seems more intuitive for our work.

Thanks for pointing out the way to use Stat-Analysis for stratification using the column value. This may also impact the way aggregations of data are plotted using METviewer. Good to be aware of this!

At this point having the capability to ensure that Point-Stat will produce one matched pair per observation certainly addressed the issue I was asking about. Thanks for all your help!

Where do I mark this discussion as answered? I see multiple places where there is a button to do this. Not sure which one is the most useful to you or does it matter?

[j-opatz]

I'm glad the tests ran smoothly and proved that going forward, the message type change will not affect the desired output.

I'll go ahead and select an response as the answer and close up this issue; no further steps are needed on your part. Again, I'm glad this fix worked for you and you can continue your work as planned!