Using PointStat Without FSCT_VAR1_LEVELS

[tonsager]

I am trying to compare gridded FCST model output with OBS on a lat-lon grid, but my data do not have any levels. Is it possible to bypass specifying FCST_VAR1_LEVELS and OBS_VAR1_LEVELS?

If I use FCST_VAR1_LEVELS = "(,)", I get this error:
ERROR : VarInfo::set_level_info_grib() - failed to parse level string '(,)'
I'm not sure why the code thinks I'm using grib.

If I put in a dummy value ('P750'), PointStat runs to completion, but the matched pairs are all rejected:
DEBUG 2: Rejected: level mismatch = 87

Is it possible to use PointStat if the data do not contain levels?

Thank you

[georgemccabe]

CORRECTION: I previously provided information to set the file_type for GridStat instead of PointStat. Updates were made inline.

Hi @tonsager , what is the file type of the forecast data you are trying to read?

If the file type is NetCDF and the dimensions of the variable are lat,lon, then the FCST_VAR1_LEVELS value you are using is correct. However, the tool cannot properly discern that the file is a NetCDF file. If the file is a CF compliant NetCDF file, you can specify this using POINT_STAT_MET_CONFIG_OVERRIDES (using METplus 4.0.0):

POINT_STAT_MET_CONFIG_OVERRIDES = fcst = { file_type = NETCDF_NCCF; }

If you are using METplus 4.1.0 (which should be released next week), then you can set:

POINT_STAT_FCST_FILE_TYPE = NETCDF_NCCF

Here is an excerpt from the MET User's Guide that contains the possible values to set for file_type:

file_type = GRIB1; GRIB version 1
file_type = GRIB2; GRIB version 2
file_type = NETCDF_MET; NetCDF created by another MET tool
file_type = NETCDF_PINT; NetCDF created by running the p_interp
or wrf_interp utility on WRF output.
May be used to read unstaggered raw WRF
NetCDF output at the surface or a
single model level.
file_type = NETCDF_NCCF; NetCDF following the Climate Forecast
(CF) convention.
file_type = PYTHON_NUMPY; Run a Python script to load data into
a NumPy array.
file_type = PYTHON_XARRAY; Run a Python script to load data into
an xarray object.

If it is GRIB file, try setting FCST_VAR1_LEVELS = L0. L is the level type identifier for a generic level type, so L0 is typically used when there is a single record.

This section of the MET User's Guide contains the more information on how to define which fields to read including a list of settings that can be used to extract records from GRIB files.

We typically recommend using the MET plot_data_plane tool to plot a field as a quick test to see if the data can be read by the other MET tools. The field info settings used with this tool will be the same to read that data by other tools.

If you continue to have issues reading your data, you can send us the file and we can take a closer look. If the file is small enough you can attach it directory to this discussion. If it is a large file, you can upload it to our FTP site. Instructions for the latter are pinned to the METplus GitHub Discussions home page.

[tonsager]

Hi George: Thanks for getting back to me so quickly. The forecast data is input using python embedding. I'm reading a non-compliant netCDF file and passing in the data in a met_data array. It is not a grib file. I'm able to successfully use GridStat using this forecast data, but I'm having trouble specifying the levels in PointStat. When I add this command: GRID_STAT_FCST_FILE_TYPE = PYTHON_NUMPY, I'm able to specify the FCST levels: FCST_VAR1_LEVELS = "(*,*)" This command also seems to work: FCST_GRID_STAT_FILE_TYPE = PYTHON_NUMPY - Are they both correct? But I'm not sure how to specify the levels with the OBS data. The OBS data are in a netCDF file I created using ascii2nc. Thank you! Terry

…

On Wed, Mar 9, 2022 at 8:54 AM George McCabe ***@***.***> wrote: Hi @tonsager <https://github.com/tonsager> , what is the file type of the forecast data you are trying to read? If the file type is NetCDF and the dimensions of the variable are lat,lon, then the FCST_VAR1_LEVELS value you are using is correct. However, the tool cannot properly discern that the file is a NetCDF file. If the file is a CF compliant NetCDF file, you can specify this using GRID_STAT_FCST_FILE_TYPE (using METplus 4.0.0 or higher): GRID_STAT_FCST_FILE_TYPE = NETCDF_NCCF Here is an excerpt from the MET User's Guide that contains the possible values to set for file_type: file_type = GRIB1; GRIB version 1 file_type = GRIB2; GRIB version 2 file_type = NETCDF_MET; NetCDF created by another MET tool file_type = NETCDF_PINT; NetCDF created by running the p_interp or wrf_interp utility on WRF output. May be used to read unstaggered raw WRF NetCDF output at the surface or a single model level. file_type = NETCDF_NCCF; NetCDF following the Climate Forecast (CF) convention. file_type = PYTHON_NUMPY; Run a Python script to load data into a NumPy array. file_type = PYTHON_XARRAY; Run a Python script to load data into an xarray object. If it is GRIB file, try setting FCST_VAR1_LEVELS = L0. L is the level type identifier for a generic level type, so L0 is typically used when there is a single record. This section of the MET User's Guide <https://met.readthedocs.io/en/develop/Users_Guide/config_options.html#fcst> contains the more information on how to define which fields to read including a list of settings that can be used to extract records from GRIB files. We typically recommend using the MET plot_data_plane tool to plot a field as a quick test to see if the data can be read by the other MET tools. The field info settings used with this tool will be the same to read that data by other tools. If you continue to have issues reading your data, you can send us the file and we can take a closer look. If the file is small enough you can attach it directory to this discussion. If it is a large file, you can upload it to our FTP site. Instructions for the latter are pinned to the METplus GitHub Discussions home page. — Reply to this email directly, view it on GitHub <#1502 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASABHXTKWTOOBT7GBJXEGSLU7DCT5ANCNFSM5QJ2YF7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ------------------------------------------------------------- Terrance Onsager NOAA/NWS/Space Weather Prediction Center 325 Broadway Boulder, CO USA 80305 1-303-497-5713 ------------------------------------------------------------- *Safeguarding society with actionable space weather information*

[georgemccabe]

Hi Terry,

Answers are in-line below.

Thanks for getting back to me so quickly. The forecast data is input using
python embedding. I'm reading a non-compliant netCDF file and passing in
the data in a met_data array. It is not a grib file. I'm able to
successfully use GridStat using this forecast data, but I'm having trouble
specifying the levels in PointStat.

Thanks for the info. There is a use case showing how to configure METplus to run PointStat using Python Embedding to read forecast data. You should be able to set:

FCST_POINT_STAT_INPUT_TEMPLATE = PYTHON_NUMPY

then set the value of FCST_VAR1_NAME to the Python script (with any arguments). You can exclude FCST_VAR1_LEVELS in this case, as it is not needed for Python Embedding.

When I add this command: GRID_STAT_FCST_FILE_TYPE = PYTHON_NUMPY, I'm able
to specify the FCST levels: FCST_VAR1_LEVELS = "(,)"

This command also seems to work: FCST_GRID_STAT_FILE_TYPE = PYTHON_NUMPY -
Are they both correct?

Yes, both options will work to set the fcst.file_type value.

But I'm not sure how to specify the levels with the OBS data. The OBS data
are in a netCDF file I created using ascii2nc.

I will address this as a reply to your other comment about reading obs data below.

[tonsager]

Hi George: In the manual, it describes the "ascii2nc ASCII Point Observation Format" I used to create my OBS file. It describes the "Level" as the "Pressure level in hPa or accumulation interval in hours for the observation value", and it is a numeric value. In my PointStat config file, it takes the OBS Level as a string. How are these values reconciled, and how do I distinguish if the Level field I use in ascii2nc is "accumulated interval in hours for the observations value" or the pressure level? Thank you, Terry

[JohnHalleyGotway]

Hi @tonsager, @georgemccabe asked me to take a look at this discussion. I see you have a question about configuring the level string when verifying against point observations in Point-Stat. By convention, the level string for observations in Point-Stat is specified as if there were for GRIB data.

Please take a look in the description of the fcst dictionary in the MET User's Guide, and then scroll down to this content about the level:

The “level” entry specifies a level type and value:
- ANNN for accumulation interval NNN
- ZNNN for vertical level NNN
- ZNNN-NNN for a range of vertical levels
- PNNN for pressure level NNN in hPa
- PNNN-NNN for a range of pressure levels in hPa

So the level is a formatted string that begins is A, Z, P, L, or R. And that is followed by a single value (NNN) or a range of values (NNN-NNN). For example, setting the obs level = "P500"; indicates that you only want to use observations for pressure level exactly equal to 500. Whereas, level = "P475-500"; indicate that you want to use any observations falling in that pressure range.

Levels starting with "Z" filter the observations based on their height. So level = "Z18-20"; would use observations whose height is between 18 and 20.

In this way, the user can filter down which observations are included the verification based on their pressure or height level.

[tonsager]

Thank you for this information. In my case, I don't have any Level information in either my FCST or OBS information. My FCST is a 2-D lat-lon grid, and my OBS are scalar values in lat-lon coordinates.

I created my OBS netCDF file using ASCII2NC with python embedding. The documentation for the 11-field OBS input indicates that the Level field is numeric, not a string. Since I have no Level information, what do you recommend I put in this field?

[JohnHalleyGotway]

@tonsager here's an example of a test we run that uses python embedding to pass point observations to ascii2nc. This really is a very, very simple example. It just reads ascii point observations from this ascii input file and then passes them in memory to ascii2nc.

The 8-th column of that sample data defines the pressure level for each obs. The 9-th column defines the height.

When configuring Point-Stat to use these observations, setting level = "P500-800"; would filter those obs by their value in the 8-th column. level = "Z1000-1500"; would filter them by the 9-th column.

Are you providing any numeric values in the 8-th or 9-th columns in that data you're passing to ascii2nc? If you're setting those all to a value of 0 (for example), you could configure Point-Stat to use level = "P0"; or level = "L0";.

If you're still stuck, please feel free to upload a more specific example. Or if the data is too big to attach here, please follow these instructions.

[tonsager]

Hi John: That was it. Thank you!!! Terry

[JohnHalleyGotway]

Great, thanks for confirming. I'll go ahead and mark this discussion as being answered.

We also "Lock conversation" on answered discussions because we've found it to be difficult to keep track of new posts to previously-answered discussions. But if more questions or issue arise, please feel free to open up a new discussion.