Writing configuration file to ingest WRF forecast data

[scatt11]

Hi MET-Help Team,
Perhaps this is an inexperience related issue, but I have not been able to write a configuration file that will read in raw WRF data. I am under the impression that this can be done without post processing for surface variables which are not staggered (e.g. 2-meter temperature). I am attempting to ingest a wrfout file into point_stat and the header of that data appears as so:

The variable (T2) is structured like so:

I have changed the config so that it expects NETCDF_PINT as the the file_type.

And the error message I am getting is related to the level of the forecast data. From the error messages, it appears that the tool is still looking for a recognized grib level? I have tried a number of different entries for the level and continue to get the same error message. Is it not recognizing that I am trying to ingest a netcdf, or have I missed something else entirley? The other odd thing I see is the messages pointing to the default config file in addition to the user config file.

Thanks in advance for any direction.

[JohnHalleyGotway]

Thanks for posting the screenshots to illustrate the issue you're having in configuring the MET Point-Stat tool.

I see how and why this behavior is confusing. You are passing a raw WRF NetCDF output file to Point-Stat and setting "file_type = NETCDF_PINT;" to tell MET to interpret it as such, but you're getting an error message about parsing a GRIB level information. This is actually an issue in how the "obs" dictionary is defined in the Point-Stat config file.

I do see that your Point-Stat config file includes this line:

obs = fcst;

That copies the forecast settings into the observation dictionary. So it tells Point-Stat to look for observations named "T2" with a level value of "(0,*,*)". And since "obs = fcst" appears in the default Point-Stat config file, it's easy to leave that setting as-is. However it only works when processing GRIB1 or GRIB2 model data. Instead, you'll need to actually define the "obs" dictionary. By convention, those configuration settings are stored as if they were for GRIB data. Please try adding:

obs = {
   field = [ { name = "TMP"; level = "Z2"; } ];
}

Does that produce any better results?

I can see that we should add some log messages to make it clear that this error occurs when parsing the "obs" dictionary.

[scatt11]

Thanks for the prompt response @JohnHalleyGotway. I had not even addressed the obs dictionary yet, so that makes total sense. And yes some more detail in the log message would be very helpful. I thought I was being cautious by only taking things one step at a time.

I added the line as you suggested and that solved the immediate problem at hand. However, this line was additionally needed in my obs dictionary to correctly read in my observations which were metar data output from madis2nc.sh
message_type = ["ADPSFC"]

I seem to remember reading somewhere that you all were working to build a database of example configuration files. If that is the case, that would be VERY helpful.

[JohnHalleyGotway]

Great, glad to hear you were able to make progress.

Let me clarify one detail... When the config entry isn't found at the expected level of context, the MET tools keep looking up to higher and higher levels of context for that entry until it's found.

To illustrate, please take a look at this line of the Point-Stat config file:
https://github.com/dtcenter/MET/blob/ba739729040dff1b513b4d44a296bc098167103f/met/data/config/PointStatConfig_default#L96

//
// Point observation filtering options
// May be set separately in each "obs.field" entry
//
message_type   = [ "ADPUPA" ];

As I'm sure you know, the message_type specifies which observations type(s) should be used for verification. The note about being set separately for each "obs.field" entry means that you can include a message_type setting for each "obs.field" array entry. For example, you may want to verify 500mb temperature against ADPUPA observations and 2-meter temperature against ADPSFC and SFCSHP observations. That'd look like this:

obs = {
   field = [
      { name = "TMP"; level = "P500"; message_type = "ADPUPA"; },
      { name = "TMP"; level = "Z2";   message_type = [ "ADPSFC", "SFCSHP" ]; }
   ];
}

So Point-Stat is parsing the "message_type" separately for each "obs.field" array entry. But usually it isn't defined there! And that's the key point here. When the config entry isn't found at the expected level of context, the MET tools keep looking up to higher and higher levels of context for that entry. And it'll eventually find "message_type = [ "ADPUPA" ];" at the highest level of context in the default config file and use that one.

Hopefully that helps clarify.

In regards to more examples, they are provided via the METplus python wrappers. Obviously, there's lots of details there. Let me start by just pointing you to the METplus user's guide:
https://metplus.readthedocs.io/en/latest/Users_Guide/index.html