Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support setting/inquiring per variable fill mode for nc3 files #383

Closed
wants to merge 107 commits into from

Conversation

wkliao
Copy link
Contributor

@wkliao wkliao commented Mar 24, 2017

This pull request is related to issue #379.
The current netCDF limits the use of APIs nc_def_var_fill and nc_inq_var_fill to NetCDF-4 files. This request eliminates such limit in order to support per-variable mode for the classic netCDF files. I developed this pull request based on branch ghpull-375 to reuse subroutine NC3_inq_default_fill_value.

Below is the summary of changes.

  1. add a new member, no_fill, to NC_var struct, so a variable can have its own fill mode.
  2. move def_var_fill outside of USE_NETCDF4 ifdef bracket in NC_Dispatch struct. Similar changes to dispatcher objects in libsrc, libsrc4, libsrcp, and libdap2.
  3. move nc_inq_var_fill outside of USE_NETCDF4 ifdef bracket in libdispatch/dvarinq.c
  4. add two new arguments, no_fill and fill_valuep, to the end of NC3_inq_var().
  5. When creating a new attribute with name _FillValue, the variable's fill mode is turned on
  6. When deleting attribute _FillValue, the variable fill mode is turned off
  7. When calling nc_set_fill, fill mode is turned on/off for all variables already defined. Any variables defined successively will also use the same mode.
  8. When calling nc_def_var_fill to turn off fill mode, the variable's attribute _FillValue is deleted, if defined.
  9. During nc_enddef, filling is done only for those variable with the fill mode turned on.

@WardF
Copy link
Member

WardF commented Mar 24, 2017

I'm not certain we want to delete _FillValue if/when a variables fill mode is turned off. If fill mode is turned off and the _FillValue is removed, there is no way to easily determine what, if any, of the existing data in the variable was created by a fill value and what was 'real' data. That is the only thing that immediately occurs to me off the top of my head; I'll take a look at this tomorrow but I'll want to knock out gphull-375 first in terms of merging. @DennisHeimbigner any thoughts on this?

@DennisHeimbigner
Copy link
Collaborator

I agree. Once turned on, _FillValue should stay defined for exactly your reason. I understand
the other point of view because of fill is turned off thru the API, then we no longer can
guarantee that the fillvalue won't appear by accident. Perhaps we should consider this proposal:

  1. once fill is turned on, it cannot be turned off.
  2. add an option to nccopy to turn off fill for a specified variable.

@wkliao
Copy link
Contributor Author

wkliao commented Mar 24, 2017

Somehow I mistakenly thought putting/deleting attribute _FillValue automatically turns on/off a variable's fill mode. I just pushed a fix.

@wkliao
Copy link
Contributor Author

wkliao commented Mar 24, 2017

FYI
After commit @ac5d8e5 above, test program tst_vars2.c failed.
The cause is related to issue #384

@WardF
Copy link
Member

WardF commented Mar 29, 2017

Holding off on evaluating this until our internal meeting to review ghpull-375 next week.

thehesiod and others added 10 commits April 27, 2017 22:26
needs to be reviewed by maintainers
It turns out that the chunksize used in the
ncio-related code must be a multiple of eight in
size.  Both memio.c and mmapio.c were
potentially violating this constraint.

See also pr Unidata#400
Fix NC_DISKLESS returns garbage data for certain files
WardF and others added 8 commits June 26, 2017 11:03
The problem was that for opendap, it is possible to use keywords
as identifiers
 when there is no ambiguity. However, the DAP2
parser lost the case of the identifier used the lower case version.
Fix is to use the actual text of the symbol when it is used as an identifier.
Also added a test case for this (kwcase.*).

Additionally cleaned up some misc. dap2 testing problems.
1. ncdap_test/tst_ncdap3.sh was using an empty test set.
   restored the testing of datasets.
2. as a consequence of Unidata#1, some tests needed to be updated with minor
   tweeks.
3. fix dapmerge to handle multiple DODS_EXTRAS attributes.
4. modify buildattribute to suppress nul characters and terminate
   the name at the first nul.
5. clean up various test scripts to remove residual, unused
   references to obsolete netcdf-4 translation.
6. export e.g. NCDUMP from test_common.in so that non-top-level
   shell scripts can access it.
@DennisHeimbigner
Copy link
Collaborator

Please do not do this. It makes our job much harder when you do these kinds
of shotgun updates.

@wkliao
Copy link
Contributor Author

wkliao commented Jul 1, 2017

I simply merged the master branch to this pull request branch.

@DennisHeimbigner
Copy link
Collaborator

I am confused. At the top of this pr, it says:
wkliao wants to merge 107 commits into Unidata:ghpull-375 from wkliao:nc3-per-var-fill
ghpull-375 has already been closed. Why are you trying to merge into it?

@wkliao
Copy link
Contributor Author

wkliao commented Jul 1, 2017

Note this 383 pull request was created based on ghpull-375 (see my first post).
Github must have kept the original message, even after 375 was merged to master

@WardF
Copy link
Member

WardF commented Jul 6, 2017

Reviewed w/ @DennisHeimbigner, will go into 4.5.1 after the 4.5.0 release.

@WardF
Copy link
Member

WardF commented Aug 16, 2017

Still on our radar but trying to get 4.5.0 out the door. Dealing with an issue now related to downstream tools handling _FillValue, see #458 for more information.

@edhartnett
Copy link
Contributor

I hope we can get this merged soon.

Firstly, it will be a very useful improvement (I too have felt the lack of this function for classic files - it's a pain).

Secondly, there are a lot of code changes in this PR, and meanwhile I am making a lot of code changes to these files for PIO.

@WardF
Copy link
Member

WardF commented Nov 3, 2017

It will be a bit; working on some other issues/PR's that predate these ones, and having to switch gears to non-netCDF work. But will return to these ASAP.

@edhartnett
Copy link
Contributor

There are an awful lot of extra changes in this PR that have nothing to do with setting the fill value in nc3 files.

What's up with that?

I really want these fill value changes, but I really wonder what is going on with all the other changes. Are we reverting a bunch of code? Some of the changes look quite scary, like changing size_t to off_t. What's going on with that?

@WardF there are loads of cmake build file changes in this PR. Is this expected?

Shall I try and isolate the fill value changes from @wkliao, based on a current version of master, and only including changes related to fill value? Fill values have become a sticking point for me in several tests, so it would be nice if these features could be added, but not if they are going to break stuff.

wkliao added a commit to wkliao/netcdf-c that referenced this pull request Dec 21, 2017
@wkliao wkliao mentioned this pull request Dec 21, 2017
@wkliao
Copy link
Contributor Author

wkliao commented Dec 21, 2017

All my changes to support setting per-variable fill mode in this PR have been extracted to #731.
In addition, I added a test program nc_test/tst_def_var_fill.c

@edhartnett
Copy link
Contributor

OK, so should this PR be closed without merging now?

@wkliao
Copy link
Contributor Author

wkliao commented Dec 21, 2017

In my opinion, it can be safely closed without merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants