[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 980213: NCVPTG in version 3

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 980213: NCVPTG in version 3
  • Date: Fri, 13 Feb 1998 10:28:10 -0700
>To: address@hidden
>From: Philippe Tulkens <address@hidden>
>Subject: NCVPTG in version 3
>Organization: Universite catholique de Louvain
>Keywords: 199802131526.IAA10430

Hi Philippe,

> I'm trying to run a NetCDF program written in FORTRAN and running on a 
> HP workstation that works with the NetCDF Version 3.
> 
> My program was used before under version 2.
> 
> The problem I have now is that with the new version 
> my code is stopped with the following error message:
> 
> NCVPTG: : Illegal stride
> 
> It concerns apparently the following line:
> 
> CALL NCVPTG(ID_FILE,VID_var,start,count,stride,imap,VAR(1,1,1),ER_code)
> 
> 
> I looked in the version 3 User's guide for the definition of the
> new equivalent function. I found NF_PUT_VARM_type functions.
> 
> I read also the definition of stride in it p 63.
> 
> In my program in version 2 I defined stride as as a vector
> of dimension 4 and as DATA /0,0,0,0/
> 
> Is that definition incompatble with version 3 ?
> 
> 
> So my question is only :
> 
> Has something changed in the definition of the parameter stride ?

We had not intended to change the meaning of the stride parameter, but
apparently we inadvertently changed the meaning of 0 strides.  The
default stride is 1, meaning get all the data along the associated
dimension, with no skipping.  A stride of 0 in netCDF-2 meant the same
as the default, but in netCDF-3 it is now an invalid value.

It was our oversight not to detect or document this change, since our
test cases did not use a stride of 0.  We are looking into whether we
can restore the old behavior for the next version, but in the mean time,
I think the only way to workaround this bug is to change your 0 stride
to 1, or continue to use netCDF-2.

Incidentally, if you are using strides but not making use of the "IMAP"
parameter, a simpler netCDF-3 equivalent would be NF_GET_VARS_type
rather than NF_GET_VARM_type.

Thanks for reporting the bug!

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu