NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Wei-keng, > My question is about how to set imapp argument in nc_put_varm(). > > At first the description of nc_put_varm() in C interface guide is > inconsistent with the > document generated by doxygen. > > In C interface guide, it says "nc_put_varm() function will write a variable > of any type, > including user defined type" > http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-c/nc_005fput_005fvarm_005f-type.html#nc_005fput_005fvarm_005f-type > > But in doxygen document, it says "nc_put_varm() function will only write a > variable of > an atomic type; it will not write user defined types." > http://www.unidata.ucar.edu/software/netcdf/docs/group__variables.html#ga48533a5a1ab3c2e883e6c862720b94ab The older C interface guide describes the intended behavior, but the doxygen document is currently correct, as there is an explicit test in libdispatch/dvar{get,put}.c to disallow user-defined types for _varm functions: if(vartype > NC_MAX_ATOMIC_TYPE) return NC_EMAPTYPE; Since the library seems to work OK for similar _vars functions for user-defined types, I think the intended behavior for _varm functions can be restored without too much effort (but the fix won't be in the upcoming 4.3.2 release). I've created an issue to track the fix: https://bugtracking.unidata.ucar.edu/browse/NCF-300 > I may not fully understand the description for argument imapp in the C > interface guide. > When I use nc_put_varm(), do I set the values in imapp[] to the distances in > number of elements > or bytes? I tested a program (extracted below) that uses both > nc_put_varm_int() and nc_put_varm(). > At first, I defined a 1-D integer array variable of size 2 in netCDF file. > The results are different between using nc_put_varm_int() and nc_put_varm(). > It looks like in nc_put_varm(), imap[] is in the units of bytes and in > nc_put_varm_int(), imap[] > is in number of integers. > > int buf[5] = {0,1,2,3,4}; > size_t start[1] = {0}; > size_t count[1] = {2}; > ptrdiff_t stride[1] = {1}; > ptrdiff_t imap[1] = {4}; > > nc_put_varm_int(ncid, varid, start, count, stride, imap, buf); > or > nc_put_varm (ncid, varid, start, count, stride, imap, buf); > > > Command ncdump shows the contents of variable are: > for nc_put_varm_int() > VAR = 0, 4 ; > for nc_put_varm_() > VAR = 0, 1 ; > > Please clarify if this is correct behavior. > > In the C interface guide, nc_put_varm requires "the type of the data > in memory must match the type of the variable". It sounds to me imap > should be the distances in units of element numbers, e.g. number of > integers in the above example. I think you're right, the imap[] argument for nc_put_varm() should be in terms of number of elements, not number of bytes. Fixing that bug has been included in the issue above. Thanks for reporting the problems! --Russ
netcdfgroup
archives: