[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 980213: NCVPTG in version 3
- 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