Hi Charlie,
The wrappers support the built-in netCDF mechanism of writing FROM any
(supported) type in your code TO any disk type, simply by virtue of the
fact that they call the appropriate netCDF interface for doing so.
For example, you of course know that you can write either an int or double
array (in your program) to a float array (on disk), if the disk var was
defined as NC_FLOAT and you go through either nc_put_var_int or
nc_put_var_double, respectively. The wrappers implement this with code
similar to the following:
-----
#define ncVar_put(TYPE) \
bool ncVar::put( TYPE *vals, size_t *offset, size_t *count, bool verbose )\
{ \
int err = nc_put_vara_ ## TYPE ( ncid, my_varid, offset, \
count, vals ); \
}
ncVar_put(int)
ncVar_put(long)
ncVar_put(float)
ncVar_put(double)
-----
For clarity I've omitted all the bells and whistles in the code that check
for errors, implement other functionality, and so on. But you can see
that they take whatever type you have in your C++ program and, by calling
the correct netCDF routine, write it to whatever type is on the disk.
You can also see I've done it with macro expansion rather than templates
because I think fundamentally, the ncVar <-> type relationship is a
"HAS_A" relationship, rather than an "IS_A" relationship, so I think
templates are not the way to go on that. (I.e., it's not that a ncVar
"IS_A" type, it's that a ncVar "HAS_A" type.)
The second part (or maybe the first part) of your question is how you
specify the type when creating vars in-memory. (If you open a netCDF disk
file, of course the var types are specified in the file and the wrappers
fully respect the specified types.) The intent of the code was to do it
via the missing value, as follows:
float missval_f(1.e35);
double missval_d(1.e35);
int missval_i(-1);
var1 = new ncVar( "Var_float", 1, dim, "units", missval_f, NULL );
var2 = new ncVar( "Var_dble", 1, dim, "units", missval_d, NULL );
var3 = new ncVar( "Var_int", 1, dim, "units", missval_i, NULL );
and so on. However, since I always make my vars floats, and I've not
distributed this code, the actual overlaid interfaces for the various type
calls are not there (not that it would be hard to add them). All the
machinery for handling different types based on the type of the missing
value is there, since that is needed for disk files, which of course can
be any type. Note that this would break on netCDF files that have a type
that is different from the type of their missing_value attribute. I
personally think having different types for those is a mistake (hence the
fact that my wrappers enforce them to be the same), but I've seen files
that do this, often in the context of handling scale_offset. (I.e., if
only shorts are stored in the file, but are expected to be expanded to
"floats" using scale and offset, should the missing value be specified as
a short or as a float?) I seem to remember that the netCDF mailing list
went through this question a while back, but frankly I don't remember what
the consensus was. I think the only safe answer is that they should be
the same type, otherwise the scale_offset conversion might introduce
rounding errors on various platforms that prevent a data value that is
supposed to be a missing_value from being recognized as such.
Regards,
--Dave
---------------------------------------------------------------
David W. Pierce / Climate Research Division
Scripps Institution of Oceanography / (858) 534-8276 (voice)
dpierce@xxxxxxxx / (858) 534-8561 (fax)
---------------------------------------------------------------
On Fri, 14 Sep 2001, Charlie Zender wrote:
> Hello Dave,
>
> Thanks for your feedback. From your example it is unclear (to me)
> how your wrappers allow specification of the external (disk)
> storage type of the variables, and this is key to my problem.
> Do they automatically assign float --> NC_FLOAT on writes and
> NC_FLOAT --> float on reads, or what?
> Will they automatically handle double --> NC_FLOAT on writes?
>
> Thanks,
> Charlie
> --
> Charlie Zender zender@xxxxxxx (949) 824-2987/FAX-3256, Department of
> Earth System Science, University of California, Irvine CA 92697-3100
>
