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.

Re: [netcdfgroup] nc_put_varm

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



  • 2014 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: