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

Re: 20050111: Netcdf fortran 90 documentation bugs



Unidata Support <address@hidden> writes:

> ------- Forwarded Message
> 
> >To: Unidata Support <address@hidden>
> >From: Mark Hadfield <address@hidden>
> >Subject: Netcdf fortran 90 documentation bugs
> >Organization: NIWA
> >Keywords: 200501110102.j0B12rv2011813 netCDF Fortran document
> 
> This is a multi-part message in MIME format.
> --------------030700080506000406000807
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Hi
> 
> I have a couple of concerns about the current docs for the Fortran 90 
> interface:
> 
> First, the documentation for NF90_DEF_VAR at
> 
>     
> http://my.unidata.ucar.edu/content/software/netcdf/docs/netcdf-f90/NF90_005fDEF_005fVAR.html#NF90_005fDEF_005fVAR
> 
> gives the correct arguments (ncid, name, xtype, dimids, varid) in the 
> function declaration section , but in the text following, "dimids" is 
> absent and "nvdims" and vdims" are substituted. (IIRC these are from the 
> Fortran 77 interface.) Also the function declaration section fails to 
> note that dimids is optional.

Thanks for pointing that one out. I've fixed it and updated the web
pages.

> Second (not an error as such) I note that the NF90_INQUIRE* functions 
> are consistently written in mixed case while the other functions are 
> consistently upper case. This is poor practice IMHO as it implies that 
> the distinction is significant in some way, whereas Fortran is 
> case-insensitive. One might argue that the NF90_INQUIRE* function names 
> are so long that they are hard to read in upper case. There is some 
> truth to this, but it leads to the obvious question: why were they made 
> so long in the first place? Why "NF90_INQUIRE_VARIABLE" when 
> "NF90_INQ_VAR" is easier to read and more consistent with the rest of 
> the interface? But I guess that's just flogging a dead horse.

I will see what can be done about this. I agree that the inquire call
violates convention, and since, as you say, fortran is case
insensitive, we should be able to just update the docs.

As for a new name for the function, that's a whole different kettle of
horses of different colors. There's user code out there that uses the
current name, so all that code would break if we changed it now. This
would result in wailing and gnashing of teeth.

Thanks for your feedback on the manuals, I would be very happy to hear
any other comments about them.

Ed Hartnett 
Unidata