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

[netCDF #CGL-874130]: Why are NC_GLOBAL and nf90_global different?

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: [netCDF #CGL-874130]: Why are NC_GLOBAL and nf90_global different?
  • Date: Mon, 15 Dec 2014 11:32:26 -0700
> In the netcdf-fortran-4.4.0 source, nf90_global=0.
> In the netcdf-4.3.2 source, NC_GLOBAL=-1.
> 
> It's my understanding that these constants have the same semantic
> meaning, and since they're both implemented as signed integers, why
> don't they have the same integer value?

Good question!

I think the answer is that nf90_global is intended to be analogous 
to NC_GLOBAL in the C interface by providing a variable ID 1 less
than the first variable ID, which in C is 0 and in Fortran is 1.
Just as the default array indexes used for C and for Fortran are
somewhat arbitrary and different, the varIDs used in the APIs for 
C and  Fortran as variable IDs for a pseudo-variable are arbitrary 
and different.  That's not a very good reason, but it's too late to
change the convention now, as it would break both code and access to
existing data in archives.

--Russ

> I discovered the difference when I wrote a C function that used the
> netcdf-4.3.2 library, and then wrote a fortran interface for it.
> 
> When my C interface with other netcdf C code, it's natural to use
> NC_GLOBAL, and that works. When using my fortran interface with other
> netcdf fortran code, it seems perfectly reasonable to use nf90_global,
> but when that's passed to my underlying C routine, a problem occurs
> because nf90_global != NC_GLOBAL.
> 
> I realize that there's an obvious workaround I can use to hide this
> problem, but the fact that such a workaround is needed at all seems
> like a bug in the netcdf library interface.
> 
> Thanks,
> -John
> 
> --
> John C. Houck
> Smithsonian Astrophysical Observatory
> 60 Garden Street, MS-50
> Cambridge, MA 02138
> Phone: 617-495-7348
> 
> 

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



Ticket Details
===================
Ticket ID: CGL-874130
Department: Support netCDF
Priority: Normal
Status: Closed