Re: [Opengrads-devel] lats4d

[Arlindo da S. <da...@al...>]

On Jan 30, 2008 9:37 AM, Jennifer Adams <jm...@co...> wrote:

> We know that the loss of the LATS interface severely impacts many users.
> But our intention is to *replace* it with something better, not to eliminate
> the functionality completely. Consider this:
> set x; set y; set z; set t; set e
> set gxout fwrite
> set fwrite -nc file.nc
> d var
> disable fwrite
>
>
Let's keep this technical discussion out of gradsusr...

My main concern about this design is that when I think of "fwrite" I think
of stream I/O in the POSIX sense, and self-describing files such as netcdf
and hdf (and their API) do not conform to the stream I/O model. Unless you
want to restrict the feature above to only write one variable per file on a
single shot, I suspect you will have to rewrite all the infrastructure in
the LATS library, including metadata setup layer and the LATS table,
specially if you are concerned about enforcing standards such as CF or being
able to write GRIB files.

You are aware that PCMDI has already set in motion the process of legally
making LATS opensource, and that folks at PCMDI are aware that LATS is used
in GrADS, have given permission for COLA to do so in the past, and have
never expressed any opposition to it. (Correct me if I am wrong.) Also, the
license does not say that you cannot modify the code; it simply states

 * Copyright:    1996, Regents of the University of California
 *        This software may not be distributed to others without
 *        permission of the author.

And as I understand it, the authors have given this permission to COLA.
Honestly, I don't understand why the license issue has now emerged as a
major impediment to continue supporting LATS in GrADS.  (Yes, I admit, this
conflicts with GPL, and we are living in sin while the paperwork takes its
course.)

Regarding the LATS code proper. I realize this is a matter of opinion, but I
consider the LATS code well written: lots of comments, modular and
extensible with even a user guide. The NetCDF-2 API it uses is the only true
interoperable API among NetCDF-2,3,4 and HDF-4, so I personally have no
issues with it. However, if one would elect to convert it to the NetCDF-3
API this could be done relatively easy given the semantic equivalence of the
two APIs.  In the past few years we have developed at GMAO a small wrapper
library (libmfhd3.a)  which adds a NetCDF-3 API to HDF-4, so converting LATS
to the NetCDF-3 API would not require us to write an HDF-4 module with the
SD interface (which in itself is a wrapper around the NetCDF-2 API with
additional features thrown in).

What exactly are the *technical issues* with LATS that makes it not a viable
alternative?
Clearly, it would need to be extended to handle a 5th dimension (although
one could start by keeping the output files 4D, not a bad idea in my
opinion) and add additional formats such as GRIB-2.

Sorry if it sounds like I am second guessing your decision, but I am really
having a hard time understanding the rationale behind it.

            Arlindo

-- 
Arlindo da Silva
da...@al...