Fix support for int64 NetCDF variable types.

[JohnHalleyGotway]

Describe the Problem

While running plot_data_plane to test out some data for dtcenter/METplus#1551, I ran across some unexpected behavior. I suspect that there's an uninitialized time variable in the vx_data2d_nccf library.

Expected Behavior

When the valid time cannot be parsed from a CF-compliant gridded NetCDF file, it should be reported as unixtime 0, i.e. 19700101. However when I rerun the same plot_data_plane command several times, sometimes it's reported correctly as unixtime 0 and other times, I see a garbage value.

Environment

Describe your runtime environment:
1. Machine: Mac Laptop
2. OS: MacOS
3. Software version number(s): MET version 10.1.0

To Reproduce

Describe the steps to reproduce the behavior:
1. Download obs.txt.gz
obs.nc.gz
2. Run plot_data_plane multiple times with "-v 4" and watch the log messages

plot_data_plane obs.nc obs.ps 'name="precipitation"; level="(*,*)";' -title "Observation precipitation" -v 4

Here's good log output:

DEBUG 4: Data plane information:
DEBUG 4:    plane min: 0
DEBUG 4:    plane max: 2.10354
DEBUG 4:    valid time: 19700101_000000
DEBUG 4:    lead time: 000000
DEBUG 4:    init time: 19700101_000000
DEBUG 4:    accum time: 000000

And here's bad log output:

DEBUG 4: Data plane information:
DEBUG 4:    plane min: 0
DEBUG 4:    plane max: 2.10354
DEBUG 4:    valid time: -21924652902-03_082952
DEBUG 4:    lead time: 000000
DEBUG 4:    init time: -21924652902-03_082952
DEBUG 4:    accum time: 000000

Please inspect the library code and look for uninitialized time variables. Please initialize them to unixtime 0.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required: @hsoh-u
• Select scientist(s) or no scientist required: none needed

Labels

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

Projects and Milestone

• Select Organization level Project for support of the current coordinated release
• Select Repository level Project for development toward the next official release or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next bugfix version

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy
  No impacts.

Bugfix 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 main_<Version>.
  Branch name: bugfix_<Issue Number>_main_<Version>_<Description>
• Fix the bug 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 main_<Version>.
  Pull request: bugfix <Issue Number> main_<Version> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Linked issues
  Select: Organization level software support Project for the current coordinated release
  Select: Milestone as the next bugfix version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Complete the steps above to fix the bug on the develop branch.
  Branch name: bugfix_<Issue Number>_develop_<Description>
  Pull request: bugfix <Issue Number> develop <Description>
  Select: Reviewer(s) and Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Close this issue.

[hsoh-u]

I cannot reproduce this problem on seneca. Would you add a whole log file with -v 5 or above?

DEBUG 4: NcCfFile::open() -> parsing units for the time variable "seconds since 1970-01-01 00:00:00 UTC"
DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention time unit string "seconds since 1970-01-01 00:00:00 UTC"
DEBUG 4:                 as a reference time of 19700101_000000 and 1 second(s) per time step.
DEBUG 4: get_nc_data(NcVar *, double *) add_offset = 0, scale_factor=1, cell_count=1, is_unsigned_value: 0
DEBUG 1: get_nc_data(NcVar *, double *) type_id: 10 type name: int64
DEBUG 4: NcCfFile::open() -> could not extract init time from the "forecast_reference_time" variable.
DEBUG 4: NcCfFile::open() -> could not extract init time from file name.
DEBUG 4: VarInfoFactory::new_var_info() -> created new VarInfo object of type "FileType_NcCF".

[JohnHalleyGotway]

@hsoh-u, while I have this issue easily reproducible on my machine and in front of me, I'll reassign to myself and take a look at it. Thanks for taking a look on seneca.

[JohnHalleyGotway]

@hsoh-u please try testing again on seneca. However, this time use the newly created bugfix_2123_main_v10.1_nccf_valid_time branch. I modified nccf_file.cc to explicitly initialize newly allocated memory to non-zero values (-10). That should make the error reproducible every time you run it.

I wasn't sure exactly how the time info should be handled in this case, so I'd like to hand it back off to you to figure out.

Please be sure to REMOVE the debug code I've added to nccf_file.cc prior to submitting a PR.

[JohnHalleyGotway]

@hsoh-u I modified the title of this issue to better describe the problem/fix.