Steve writes:
> First off, a semantic correction is in order. Contrary to your subject
> line, our implementation of netCDF is not incorrect. Remember that
> netCDF is an API and not a data format. Consequently, only if a netCDF
> implementation violates the netCDF API can it be considered incorrect.
> Our netCDF implementation does not; therefore, it is correct.
>
I agree in 100.00 %. We used (and I myself took over) a very
unfortunate subject in our emails. We should have written something
like this: "unexpected way of growth". I simply do apologize for being
so careless.
On the other hand, it is really unfortunate that the user cannot
know how the NetCDF Data Model is implemented in terms of
XDR-elements. A few months ago I sent an email to Steve (or Glenn, I
don't remember) asking about the same thing. I am still much
interested in the physical efficiency of NetCDF. The schema used by
NetCDF may be like this:
-------------
| Application |
-------------
1------> |
NetCDF interface libs.
2------> |
XDR lib.
3------> |
------------------------
| physical FILE on disc |
------------------------
Interface 1 is is fully described in NetCDF User's Guide.
Interface 3 is is fully described in XDR standard.
Interface 2 is known only for Unidata: how the data model is mapped
into a file structure. This the corner stone of the storage space and
access-time efficiency.
Does already exist a specification of Interface 2, other than a
commented C-source I received from Unidata some time ago?
Gabor Fichtinger
Scientific Visualization Group,
Center for High Performance Computing
The University of Texas System
Balcones Research Center, 1.154 CMS
10100 Burnet Road, Austin, TX, 78758-4497
Ph. : (512) 471 2409
Ph. : 1-800-262-2472/2409 (toll free)
Fax : (512) 471 2445
Email: gabor@xxxxxxxxxxxxxxx
__o
__o -\<,
-\<, __________O / O
___________O / O
