Enhance MET to handle NC strings when processing CF-Compliant NetCDF files.

[JohnHalleyGotway]

Describe the Enhancement

This enhancement request arose via GitHub discussions:
dtcenter/METplus#1416

MET versions 10.0.0 and 10.1.0 are not able to read CF-compliant NetCDF files from:
https://www.nohrsc.noaa.gov/snowfall_v2/

Attempting to plot this data with plot_data_plane results in this error:

plot_data_plane sfav2_CONUS_24h_2022020718.nc plot.ps 'name="Data"; level="(*,*)"; file_type=NETCDF_NCCF;'
...
ERROR  : 
ERROR  : NcCfFile::get_grid_from_grid_mapping() -> Cannot extract grid mapping variable ((nul)) from netCDF file.
ERROR  : 

The underlying problem is that the variable attributes are specified as NetCDF strings instead of character arrays. This task to enhance MET's vx_data2d_nccf library (or vx_nc_util) to handle the use of these strings.

For example, the "string" in front of units and stardard_name prevents MET from parsing these attributes:

	double lat(lat) ;
		string lat:long_name = "latitude" ;
		string lat:units = "degrees_north" ;
		string lat:standard_name = "latitude" ;
		lat:resolution = 0.04 ;
		lat:origin_offset = 0.02 ;
		string lat:bounds = "lat_bounds" ;

To test, I used ncdump/ncgen to strip out the "string" settings and re-ran plot_data_plane:
sfav2_CONUS_6h_2022020718.nc.gz

ncdump sfav2_CONUS_6h_2022020718.nc | sed 's/string //g' > sfav2_CONUS_6h_2022020718.ncdump
ncgen -o sfav2_CONUS_6h_2022020718-char.nc sfav2_CONUS_6h_2022020718.ncdump
plot_data_plane sfav2_CONUS_6h_2022020718-char.nc plot.ps 'name="Data"; level="(*,*)";'

Creates this plot:

While I see that the "Data" variable does include some timing information, it is not encoded in a CF-compliant way. If you have any control over the creation of this data, I'd recommend following the conventions for the "Time Coordinate".

Time Estimate

Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.

Sub-Issues

Consider breaking the enhancement down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

2771021

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy

Enhancement Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding Source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[JohnHalleyGotway]

@hsoh-u should we classify this issue as an "enhancement" or a "bug"?

In this comment, you indicate that MET should be able to read NC-string type variable attributes.

However, that does not SEEM to actually be working. All of the "string" type global and variable attributes really do store strings, not numeric values. If this is something that should be working but isn't, perhaps we should reclassify it as a bug and fix it for MET version 10.1.0.

What do you think?

[hsoh-u]

The API for NC_STRING does not work (NetCDF code).

• NcAtt::getValues(string& dataValues) fails
  • It calls NcAtt::getAttLength() and it returns 1 - ->fail to get the string (attribute) length
  • It calls nc_get_att_text(at netcdf-c/libdispatch/dattget.c) and returns the error code -56 (NC_ECHAR)

[hsoh-u]

I think it's enhancement. NC_STRING is not a primary type and API does not work.

[hsoh-u]

The same result with netcdf-c-4.9.0 (compile with g++ (Debian 8.3.0-6) 8.3.0). The C++ API throws an exception. Using C API does not help.
Note: netcdf-cpp was not updated (netcdf-cxx4-4.3.1).