netcdf formatted dump index reporting incorrect

[WardF]

Originally reported by Tim Hoar at NCAR:
#1 - YES, I know the default indexing is C-based.
#2 - YES, the problem occurs whether I use -f f -or- -f c
#3 - YES, it happens with multiple versions.
#4 - YES, it happens with multiple files.

I’m on yellowstone, using

0[2180] yslogin6:~/<3>models/jules/work $ module list

Currently Loaded Modules:

1. ncarenv/1.0 2) ncarbinlibs/1.1 3) intel/12.1.5 4)
   ncarcompilers/1.0 5) netcdf/4.3.0

0[2181] yslogin6:~/<3>models/jules/work $ date
Wed Dec 30 12:54:18 MST 2015

0[2182] yslogin6:~/<3>models/jules/work $ pwd
/glade/p/work/thoar/DART/jules/models/jules/work

0[2184] yslogin6:~/<3>models/jules/work $ ncdump -f f -v
land_tile_fractions check_me_out.nc > netcdf_4_3_0_dump.txt

and I think the indexing is wrong … land_tile_fractions is dimensioned
(9,1,14), I’m asking for a Fortran-style indexing scheme, and I only get the
rightmost index going up to 13, AND … worse, I get TWO (1,1,1) values …
seems like all the items that should be indexed 14 get incorrectly
addressed as a duplicate of a previous value. The DATA is correct, just
the indexing is wrong.

Please check the attached log and I’ve included the netCDF file in question.
I have used both 4_3_0 and 4_3_3 with multiple netCDF files and believe
this problem is repeatable across these tests.

[WardF]

This issue was addressed partly in one of the 4.4.0 release candidates, but an issue remains as follows:

New Client Reply: netcdf formatted dump index reporting ... wrong

Sorry - this is still not correct:

    ...
    0,   // land_tile_fractions(13,1,1)
    0,  // land_tile_fractions(15,1,1)
    ...

should be:

    ...
    0,   // land_tile_fractions(13,1,1)
    0,  // land_tile_fractions(*14*,1,1)
    ...

The 'x' dimension should go from 1 to 14 ... the 15 is too much.

[WardF]

Attached are the files provided by Tim for debugging this issue, as well as the output from the netcdf_4.4.0-rc5 test:

check_me_out.nc.zip
netcdf_4_3_0_dump.txt
netcdf_4.4.0.rc5_dump.txt

[WardF]

The issue was an off-by-1 error in how/when the last row was being printed with annotations. Issue only affected annotations, not the actual data from the file. Fix is in branch gh181, merging into master.