Re: [Opengrads-devel] lats4d

[Brian D. <do...@co...>]

Arlindo, with version 2 we are taking a long term view of GrADS and  
not focusing on short term issues.  It is our judgement that over the  
next 5 years and beyond it will be less work overall for us to re- 
implement the data output capability of GrADS rather than to go  
forward with the prior implementation.  This decision is based on a  
number of factors, not all of them technical.  While it is desirable  
to maintain upward compatibility, we of course view an entirely new  
version of GrADS as an opportunity to put GrADS on the right track  
for the future.  We must work towards an extremely stable code base.   
We cannot keep patching and putting out fires and still have time to  
implement the new features that COLA and others need -- and COLA  
needs rapid improvements to GrADS on a number of fronts.  The  
ensemble dimension is just the first major item.  The many new data  
formats already released or in the pipeline have already been  
discussed and these are external forcings we have no control over.   
We have warned you a number of times over the last couple years of  
our intention to come out with a new version that will change many  
things including lats, and this code will continue to have a rapid  
rate of improvement for another year or two and perhaps longer.   
GrADS is first and foremost a tool for COLA and the research  
community to meet strategic research goals going forward.  If the  
situation were different and we had more staff and resources perhaps  
we would have been able to support more legacy code.  But we must  
face the reality of what we have and fit our project into those limits.

And as already stated, we have not yet had time to re-implement the  
data output feature, since we have released v2 somewhat earlier than  
we had intended due to NCEP's grib2 timeline.  We have ben working  
very hard ever since NCEP announced their changeover date to get v2  
to the best state possible for that deadline... Brian

On Jan 30, 2008, at 12:31 PM, Arlindo da Silva wrote:

> 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...